Call for Submissions: GNU Radio "Block Party" Articles for ARRL QEX Magazine

[Michelle Thompson]

Call for Submissions: GNU Radio "Block Party" Articles for ARRL QEX Magazine

You are invited to contribute an article for ARRL QEX Magazine. The QEX
editor Kai Siwiak (https://www.linkedin.com/in/kai-siwiak-002123/) at
ARRL's QEX Magazine (http://www.arrl.org/qex) is open to and interested in
publishing a number of articles about GNU Radio Blocks!

This may become a regular series of articles. Authors receive financial
compensation for accepted contributions and make a direct and enduring
contribution to increased technical expertise in the amateur radio
community with their published work.

What do you need to do?
1) pick a block!
2) use the template!
3) write your amazing 1000-1500 word article!
4) submit your article! If you want it to be considered for this special
category of writing, please send it to me at w5...@arrl.net
5) enjoy being able to teach the amateur radio world more about GNU Radio,
one block at a time.

Here is the GNU Radio Block Party article template.

A. Introduction

GNU Radio is a free and open-source software development toolkit. It
provides signal processing blocks that implement software radios. GNU Radio
can be used with readily-available low-cost external RF hardware to create
software-defined radios, or without hardware in a simulation-like
environment. GNU Radio is widely used in amateur radio.

GNU Radio is used in a format called flowgraphs. These graphs are composed
of functional blocks. Each of these blocks performs a specific task. Each
block is connected to other blocks by inputs and/or outputs. Connections
between blocks are represented on the screen as directional arrows.

Flowgraphs look very much like traditional system block diagrams.
Flowgraphs can serve as a description or documentation of a radio
architecture. Unlike a block diagram on a sheet of paper, GNU Radio
flowgraphs operate directly on live signals, can do almost any digital
signal processing, and produce a huge variety of useful signals.

B. Introduce and Describe Your Block



Introduce a block of interest to radio amateurs.
Describe the block's function in detail.
Describe an application where this block would be used.
Include any necessary theory for understanding this block.
Provide or reference an example flowgraph.

C. Writing Prompts

Use some, all, or none of the following Writing Prompts. These are
suggestions to spark your creativity and are not coverage requirements.

What does this block "really" do?
Is the function "under the hood" not exactly the same as what people assume
it to be?
Is this block designed for a particular type of communication or for a
particular community?
What would the equivalent hardware circuit look like?
Does the block have no achievable equivalent in hardware?
What is the advantage to using a software component instead of the
equivalent hardware?
Who are the primary contributors? Why did they write this block? If they
had to do it over, what would they do differently?
Are there any open issues with this block? If someone wanted to help with
this block, how would they contribute?
How do digital samples get into and/or out of this block?
Does this block require other blocks to work properly?
What is configurable in the block?
What things can't be changed in this block?
Are there any quirks?
Are there any "war stories" in this block's history?
Have there been any major bugs with this block?
Is there a way this block can be mis-used or create unexpected results?
Is the block computationally efficient, or not? Why?
Does the block use any notable or unusual programming or mathmatic
techniques?


D. Questions? Comments? Critique? Please let me know at:

w5...@arrl.net

-Michelle W5NYV

Re: Multiple GNU Radio versions installed in parallel. Viable?

[Derek Kozel]

Hi Anton,

It is very possible to have multiple versions installed in parallel and 
even not that difficult (on Linux). PyBOMBS does indeed specifically 
support installing different versions into different environments and 
selectively activating them. Keeping your system install is likely to 
cause issues since it will always be in the library paths no matter what 
other version/prefix is active.


PyBOMBS is generally stable, the recipes are in a separate repository 
that is a little more active. Both do need more testers and contributors 
to keep them working entirely smoothly though.


Anaconda is increasingly popular and stable for setting up separate 
environments.

https://wiki.gnuradio.org/index.php/CondaInstall

Personally I just use CMake to specify different install locations when 
building from source and then have a short script to activate an 
environment. Not the most robust, but simple and effective.


In the GNU Radio source directory, or an OOT source directory:

cmake -G Ninja -B build-${PREFIX_NAME} -S . 
-DCMAKE_INSTALL_PREFIX=${PREFIX_PATH}

cmake --build build-${PREFIX_NAME} --target install

A setenv.sh script:

prefix="gr310"
export PREFIX_NAME=${prefix}
export PREFIX_PATH=$HOME/prefixes/${prefix}
export PATH="$HOME/prefixes/${prefix}/bin:$PATH"
export LD_LIBRARY_PATH="$HOME/prefixes/${prefix}/lib:$LD_LIBRARY_PATH"
export LIBRARY_PATH="$HOME/prefixes/${prefix}/lib:$LIBRARY_PATH"
export 
PKG_CONFIG_PATH="$HOME/prefixes/${prefix}/lib/pkgconfig:$PKG_CONFIG_PATH"
export 
PYTHONPATH="$HOME/prefixes/${prefix}/lib/python3/dist-packages/:$PYTHONPATH"


Activated with `source setenv.sh`

The only currently known issue with running multiple versions like this 
is that the preferences file is shared between them and there have been 
one or two bugs with conflicts. I don't think they're a problem with the 
latest 3.8 and 3.9 releases and there's a longer term rework to 
preferences in review.


Cheers,
Derek

On 29/06/2021 19:59, Anton Ottosson wrote:


Hi,


I have been using (or learning to use) GNU Radio 3.9.2 for a couple of 
weeks now, and for the last few days I've had some trouble with it 
(specifically 
https://lists.gnu.org/archive/html/discuss-gnuradio/2021-06/msg00106.html 
). 
For this reason I am thinking about trying the 3.8 version instead. I 
also intend to be using the extension 
https://github.com/bastibl/gr-ieee802-11 
 and I think that might go 
smoother with 3.8 as well. Now, the best thing would be if I could 
have both versions installed in parallel, so here are a few questions 
about that:



- Is it viable to run both 3.9 and 3.8 on the same machine (without 
using virtual machines), or will it be more trouble than it is worth?


- What is the best way to do this? PyBOMBS 
(https://github.com/gnuradio/pybombs 
) looks promising, because it 
installs "into a specified user directory rather than in the system 
files" (from the README). But I notice that the repo has not seen any 
action in the last few years, so maybe PyBOMBS is dead?


- If I use PyBOMBS, can I keep my current 3.9 installation (installed 
"in the system files" by package manager, via PPA) and additionally 
install 3.8 with PyBOMBS? Or will this be a mess?



Best regards,

Anton

Re: N310 phase sync issue with antenna array

[Johannes Demel]

Hi Larry,

Which carrier frequency do you use for your tests? Something like 2.4GHz?
do the 4 receive channels have a stable phase between them? i.e. if you 
don't move the transmit antenna or your RX array, the phases do not change?


I assume you have 1 TX antenna and 4 RX antennas. I would expect that 
your N310 receives this signal with a stable phase and time aligned.


However, your wireless channel will introduce a phase shift (you 
compensated it with a delay, if I understand correctly). This is 
expected and introduced by your wireless channel.
In your wired test case you fixed the "different distances" issue by 
using same-length cables.


> What I believe should be the expected results of this setup is that 
each AD9371 should receive synchronous signals aligned in phase, with a 
random 180 degree offset between each AD9371 transceiver (please correct 
me if this assumption if wrong).


Your assumption is probably wrong. You can only expect a fixed phase 
relation between your RX antennas. Your RX signal will not have the same 
phase on all RX antennas. And there might still be a 180 degree ambiguity.


In case you aim for a SIMO configuration, you need to do channel 
estimation for every RX stream.


Cheers
Johannes


On 29.06.21 22:51, Larry wrote:

Hello everyone,

I am having an issue with achieving a phase-synchronous RF configuration 
using an N310 with an Octoclock and a linear antenna array. What I 
believe should be the expected results of this setup is that each AD9371 
should receive synchronous signals aligned in phase, with a random 180 
degree offset between each AD9371 transceiver (please correct me if this 
assumption if wrong). Here is a summary of my setup, issues, and outcomes:


1)  Hardware/software setup: Using an N310 running HG image at 1-gigabit 
network connection on UHD version 3.15 on Ubuntu 18.04. This is 
supported by an Octoclock-G serving as the 10MHz reference and PPS 
source for the N310. Equal length cables are used between all channels 
of the N310, to facilitate better phase synchronization. My GnuRadio 
flowgraph consists of a USRP source into a simple squelch, feed forward 
AGC, frequency xlating fir filter, and then converted from complex to 
real going into a QT time sink.


2) Testing & results: I am attempting to receive a bursty signal using a 
four element linear dipole antenna array, with the elements spaced 
slightly under lambda/2 distance apart. Two main tests have been 
performed; one with the N310 directly wired to another SDR that is 
injecting a generated sine wave into the N310, and another test over the 
air using a radio transmitter.


i. Testing with a wired connection results in the correct expected 
results - phase-aligned signals, with the channel pairs on each AD9371 
transceiver offset by presumably + or - 180 degrees. I can then align 
using simple delays to achieve phase alignment between all channels. 
This works with 2, 3, or 4 channels used.


ii. Testing over the air results in very unsynchronized signals among 
all four channels. These results tend to be repeatable and consistent in 
their behavior, but the channels all are received both wildly out of 
phase (even channels on the same AD9371 transceiver), and even 
(depending on location of the transmitter relative to the antenna array) 
inverted in amplitude relative to other channels (particularly 
interesting was that the imaginary component of one channel would match 
the inverse of a different channel's real component). This test has been 
performed at ranges exceeding 75~ feet, and as near as 5 feet away. The 
results are similar in either situation. It is also worth noting that 
varying the transmitter's location parallel to the antenna array 
(finding a 'sweet spot', so to speak) resulted in at most 2, possibly 3 
of the channels to align properly in phase without calibrating using 
delays (at least one channel would always stay wildly different). 
Testing over the air using fewer than 4 channels yields marginally 
improved, but overall similarly poor results.


I have tried using an external LO source for the N310 as well as 
operating the Octoclock with and without GPS functionality enabled. I 
have varied the sample rates, distances, and testing environments as 
well as changing cables and splitters to try to rule out any hardware 
component errors. These seem to have no real impact on the strange 
results I get with the over the air RF configuration. Any help to sanity 
check or troubleshoot my issues would be greatly appreciated. Thank you!

Re: Fwd: spectrum analyzer problem

[Fabian Schwartau]

OK, yes, I think this is a bug.
In
https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/lib/freq_sink_c_impl.cc#L553
The data is converted using the fft() function and averaged after that.
But the fft() function already converts the transformed data into the
logarithmic scale in
https://github.com/gnuradio/gnuradio/blob/master/gr-qtgui/lib/freq_sink_c_impl.cc#L359
Averaging after the conversion to dB will yield wrong values, as
log(a+b) != log(a) + log(b).

Fabian

Am 30.06.21 um 15:29 schrieb Ali G. Dezfuli:
> 
> 
> -- Forwarded message -
> From: *Ali G. Dezfuli* mailto:ali69...@gmail.com>>
> Date: Wed, Jun 30, 2021 at 4:56 PM
> Subject: Re: spectrum analyzer problem
> To: Fabian Schwartau mailto:fab...@opencode.eu>>
> 
> 
> thanks a lot, Fabian,
> 
> I asked about the mapper itself and not pulse shaping (RRC). After some
> tests, I finally get to the problem of the spectrum analyzer (QT GUI
> Freq. Sink).
> I attached the grc photo to make my problem clearer.
> About the version, I really really like to be up-to-date but that's the
> matter of the OOT delay to move to the latest versions of GR and I
> really need them as well.
> 
> On Wed, Jun 30, 2021 at 2:29 PM Fabian Schwartau  > wrote:
> 
> Hi Ali,
> you should provide an example flow graph.
> And I think I heard several times on this list, that you should not use
> version 3.7 any more, as it is fairly old and not maintained any more.
> Nevertheless, I hacked together a small flowgraph, where I cannot
> reproduce your problem. I generate a QPSK constellation, the output RMS
> value is 1 (which makes the peak values slightly larger than 1!) and the
> 1000 point FFT with a rectangular window shows -30 dB. When you generate
> a constellation with 2 samples per symbol and make the symbol values to
> have a value of 1, you will probably get 3 dB less than expected, as the
> intermediate samples have less power than 1.
> Attached is the flowgraph and the results.
> 
> Best regards,
> Fabian
> 
> Am 30.06.21 um 11:19 schrieb Ali G. Dezfuli:
> > Hi all,
> >
> > I wonder if this is a bug or what:
> > I just make a QPSK constellation on the unit circle with quite random
> > data and
> > look at the spectrum by "QT GUI Frequency Sink" block in GRC.
> > With these parameters:
> >     FFT size = 1000
> >     Window type = None OR Rectangular
> > I should see a flat line as the spectrum with -30 dB (= -30 dBW) but
> > surprisingly it
> > shows -33 dB !!!
> > I use GNU Radio Companion 3.7.13.4 and ubuntu 16.04.
> > Would be grateful if you could help me in this matter.
> >
> > regards,
> > Ali
> 

Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

[Anton Ottosson]

Hi Vasil,


> First you need to import square2_ff from howto similar to line 13 and then 
> you can use square2_ff directly without howto infront.


It shouldn't matter whether I use `howto.square2_ff()` or import and then use 
`square2_ff()`. Both should work in python. But anyway, this was of course 
something I tried, and it did not help. However, the error message is different 
and might provide clues as to what causes the issue. This is the error message 
I get when I try to import first:


~/gr-howto/build$ ctest -V
UpdateCTestConfiguration  from 
:/home/antonott/gr-howto/build/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/home/antonott/gr-howto/build/DartConfiguration.tcl
Test project /home/antonott/gr-howto/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: qa_square_ff

1: Test command: /usr/bin/sh 
"/home/antonott/gr-howto/build/python/qa_square_ff_test.sh"
1: Test timeout computed to be: 1000
1: .E.
1: ==
1: ERROR: test_002_square2_ff (__main__.qa_square_ff)
1: --
1: Traceback (most recent call last):
1:   File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 31, 
in wrapped
1: endp = [(p.to_basic_block(), 0) if hasattr(p, 'to_basic_block')
1:   File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 32, 
in 
1: else (p[0].to_basic_block(), p[1]) for p in points]
1: TypeError: 'howto.howto_python.square2_ff' object is not subscriptable
1:
1: During handling of the above exception, another exception occurred:
1:
1: Traceback (most recent call last):
1:   File "/home/antonott/gr-howto/python/qa_square_ff.py", line 52, in 
test_002_square2_ff
1: self.tb.connect(src, sqr, dst)
1:   File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 34, 
in wrapped
1: raise ValueError("Unable to coerce endpoints: " + str(err))
1: ValueError: Unable to coerce endpoints: 'howto.howto_python.square2_ff' 
object is not subscriptable
1:
1: --
1: Ran 3 tests in 0.003s
1:
1: FAILED (errors=1)
1: DEPRECATED: Using filename with gr_unittest does no longer have any effect.
1/1 Test #1: qa_square_ff .***Failed0.22 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.22 sec

The following tests FAILED:
  1 - qa_square_ff (Failed)
Errors while running CTest

And by the way, the connect syntax `self.tb.connect(src, sqr, dst)` is not 
responsible for the error. I get a similar error if I use `self.tb.connect(src, 
sqr)` followed by `self.tb.connect(sqr, dst)` (as in the previous test).

> Usually you would add a separate qa_* class for each block you have.

Sure, but I am just following the tutorial here. In fact I tried adding a 
separate QA class for the second block in an earlier attempt to get past the 
problem, but I ran into trouble then as well. I might take another look at that 
though.

> Not sure what you mean by "reflection" here.

Testing frameworks typically use reflection 
(https://en.wikipedia.org/wiki/Reflective_programming) to set up and run the 
tests. And the OOT tutorial specifically mentions that "Unittest uses Python's 
reflection mechanism to find all methods that start with test_ and runs them.".

Best regards,
Anton


From: Vasil Velichkov 
Sent: Wednesday, June 30, 2021 7:33 AM
To: Anton Ottosson
Cc: Discuss Gnuradio
Subject: Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

Hi Anton,

On Tue, Jun 29, 2021, 21:04 Anton Ottosson 
mailto:anton...@kth.se>> wrote:

1: Traceback (most recent call last):
1:   File "/home/antonott/gr-howto/python/qa_square_ff.py", line 50, in 
test_002_square2_ff
1: sqr = howto.square2_ff()
1: NameError: name 'howto' is not defined

First you need to import square2_ff from howto similar to line 13 and then you 
can use square2_ff directly without howto infront.

  from howto import square_ff, square2_ff
  sqr = square2_ff()


1: --
1: Ran 3 tests in 0.003s
1:
1: FAILED (errors=1)
1: DEPRECATED: Using filename with gr_unittest does no longer have any effect.
1/1 Test #1: qa_square_ff .***Failed0.22 sec

Usually you would add a separate qa_* class for each block you have.

Though I guess since the unit tests are executed with reflection anything is 
possible.

Not sure what you mean by "reflection" here.

Regards,
Vasil

spectrum analyzer problem

[Ali G. Dezfuli]

Hi all,

I wonder if this is a bug or what:
I just make a QPSK constellation on the unit circle with quite random data
and
look at the spectrum by "QT GUI Frequency Sink" block in GRC.
With these parameters:
FFT size = 1000
Window type = None OR Rectangular
I should see a flat line as the spectrum with -30 dB (= -30 dBW) but
surprisingly it
shows -33 dB !!!
I use GNU Radio Companion 3.7.13.4 and ubuntu 16.04.
Would be grateful if you could help me in this matter.

regards,
Ali