GNU Radio, One Step at a Time: May 2025

Thursday, May 29, 2025

Re: SDRA-2025

Dear lists,

the programme of this year's, 11th Software Defined Radio Academy (SDRA) is ready:

Programme · Software Defined Radio Academy 2025

The conference will take place on June 28 starting at 1000 local time, which is 0800 UTC.

We will stream the conference again, as in the past years, in our YouTube channel at:

https://youtube.sdra.io

You will have the possibility to contribute your questions in the stream's chat, and we will relay them on site to the speakers. So this is truly interactive.

In case you want to attend in person, we will be in the hall "Berlin" in the conference center "East" at the HAMRADIO convention in Friedrichshafen.

Already for now, I would like to express our gratutude for the excellent contributions. We're looking forward to host this 11th SDRA.

See you soon!

BR / vy73
Markus DL8RDS
Michael DK5HH

15. März 2025 23:22, mheller@relix.de schrieb:

** apologies for cross-posting **

Call for Contributions: SDRA-2025 Online and Friedrichshafen

HAMRADIO Friedrichshafen Software Defined Radio Academy 2025 (SDRA-2025)

Date: Friday 27.06.2025, Saturday 28.06.2025 (and Sunday 29.06.2025)

Conference Websites:

https://www.hamradio-friedrichshafen.de

https://2025.sdra.io

SDRA-2025 invites radio amateurs and researchers from acadaemia and industry to submit papers for oral and poster presentations on recent research that addresses theoretical aspects, algorithms, applications, hardware and software architectures for applied Software Defined Radio systems and resources and other aspects of SDR, as well as survey and discussion papers. The invitation particularly addresses open source research and projects. We also particularly invite specialists giving introductory talks and tutorials on SDR technologies.

Ulrich L Rohde Award

The Ulrich L Rohde Award was created in 2022 and shall be granted for innovative research in the field of Software Defined Radio. It is a paper award, which requires a written submission by applicants. There is a first, second and third place being awarded with the amount of 500, 300 and 100 Euro.

All submitted papers are eligible for the award.

Award Committee:

Prof. Dr. Michael Hartje, HS Bremen, DK5HH

Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM

Prof. Dr. Hervé Boeglen, Univ. Poitiers, F4JET (European GNURadio Days)

Prof. Dr. Jean-Michel Friedt, FEMTO-ST, Univ. Besancon (European GNURadio Days)

SDRA Topics:

Advances in GNURadio related projects and research

Algorithms, applications, architectures in SDR systems

Real Time signal processing

Innovative applications using modern ADC/DAC environments

Submission Information

How to submit: Please send an abstract of approximately 250 words to:

sdra@darc.de

Please include the following information:

Paper title

Author's name (and callsign). Names and callsigns of all authors if multiple authors.

Author's affiliation

Country

Email address of the main author

All accepted papers will be published. Publication details will be available at a later point of time.

We ask authors to keep a limit of 6 pages. If there is a reason why the paper should be longer, please contact us.

We also solicit Posters and Demo papers: Poster/Demo papers describe a small focused result, a negative result, or a late-breaking result, or a description of a system that can be demonstrated on-site at the conference.

Papers should be formatted using the IEEE A4 templates: https://www.ieee.org/conferences_events/conferences/publishing/templates.html

Note that applications for the Ulrich L. Rohde Award must be submitted in form of a written paper.

Organization

Prof. Dr. Michael Hartje, DK5HH

Markus Heller, M.A., DL8RDS

Senior Programme Committee

Prof. Dr. Michael Hartje, HS Bremen, DK5HH

Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM

Prof. Dr. Michael Mächtel, HTWG Konstanz, DL2SBS

Important Dates:

Please note that we welcome earlier recordings. The earlier you can submit and arrange the recording with our video team, the better.

Abstract Submission: 30.04.2025

Acceptance Notification: 15.05.2025

Presentation Recording: 15.05.2025 - 15.06.2025

PlayOut Date and Live Event: 27/28/29.06.2025

Contact

For enquiries and paper submission details please do not hesitate to contact us:

Email: sdra@darc.de Tel.: +49.173.3835315

Re: sample rate with selector and throttle blocks

Rick,

Got it. I understand your question better now. I can't give you a fully confident answer to this, but here is an answer nonetheless. If you look at the code for the throttle block (linked below), you will see it calls "std::this_thread::sleep_until(some_time)" as the mechanism for CPU throttling. Since this call is in it's "work" function, it leads me to believe that the throttle block should only have an effect on the flowgraph if it has samples to process at the input. Otherwise, the work function will never get invoked by the scheduler.

https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/throttle_impl.cc

While this logic seems sound to me, I recall some discussion many years ago along the lines of "if the throttle block exists anywhere in the flowgraph, then it has an effect". Maybe this was never true, or is out-dated information. Hopefully someone can add to my answer more confidently.

Rich

On Thu, May 29, 2025 at 11:26 AM Rick Smegal <rsmegal@aardvarr.ca> wrote:

Correction: ''path holding throttle block" should be "path holding the
null sink".

On 2025-05-29 11:22, aardric via "GNU Radio, the Free & Open-Source
Toolkit for Software Radio" wrote:
> Richard,
>
> Thanks for the quick reply. I understand the need for a throttle.
> However, in my case, if the selector block selects the path holding the
> throttle block then the hardware does not appear to throttle which makes
> sense because the hardware isn't being fed data; in this case the CPU
> then runs wild. I am seeking confirmation that reciprocity holds in
> that if the throttle block is not receiving a stream of data (not in the
> active path), it will then have no impact and the hardware will
> determine the actual sample rate.
>
>
> Rick
>
> On 2025-05-29 11:13, Richard Bell wrote:
>> Hello,
>>
>> TLDR: If you are using hardware in your flowgraph, which I think you
>> are, then you should not include a throttle block. Only use throttle
>> blocks in flowgraphs with no hardware limitations (i.e. reading from
>> files or generating synthetic data on the fly).
>>
>> The throttle block is intended for software only scenarios, in which
>> you want to limit the rate at which your CPU gets called to make
>> computations. The throttle block simply invokes a call to sleep to
>> artificially "throttle" the CPU usage. It is not related to the
>> contextual sample rate of the underlying stream of data. Using a
>> throttle block with hardware can cause unintended issues where you
>> can't keep up with the rate of the hardware.
>>
>> For example, I could record data to a file from a radio with a sample
>> rate of 1 Msps. If I play back that file and plot it in GNU Radio, I
>> could use a throttle with any rate I want to limit CPU usage, but the
>> underlying sample rate of that data will always be 1 Msps. The rate of
>> CPU usage and the underlying sample rate of data are not coupled.
>>
>> Richard
>>
>>
>>
>> On Thu, May 29, 2025 at 10:57 AM aardric via GNU Radio, the Free &
>> Open-Source Toolkit for Software Radio <discuss-gnuradio@gnu.org> wrote:
>>
>> Hi,
>>
>> Could someone please confirm my understanding that the sample
>> rate in
>> the attached flow graph will be determined by the active path of the
>> second (from left) selector block and NOT the throttle block (that
>> is,
>> if throttle not selected)? This would be consistent with the block
>> documentation for the selector block on the wiki.
>>
>>
>> Rick
>>

Re: required c++ language standard

On Thu, May 29, 2025 at 2:39 AM Johannes Demel <jdemel@gnuradio.org> wrote:

Expect the minimum C version to be bumped soon to give contributors the opportunity to enjoy later language features.

Wouldn't it make more sense to wait until someone actually used one of those features?

Matt

Re: sample rate with selector and throttle blocks

Richard,

Thanks for the quick reply. I understand the need for a throttle.
However, in my case, if the selector block selects the path holding the
throttle block then the hardware does not appear to throttle which makes
sense because the hardware isn't being fed data; in this case the CPU
then runs wild. I am seeking confirmation that reciprocity holds in
that if the throttle block is not receiving a stream of data (not in the
active path), it will then have no impact and the hardware will
determine the actual sample rate.

Rick

On 2025-05-29 11:13, Richard Bell wrote:
> Hello,
>
> TLDR: If you are using hardware in your flowgraph, which I think you
> are, then you should not include a throttle block. Only use throttle
> blocks in flowgraphs with no hardware limitations (i.e. reading from
> files or generating synthetic data on the fly).
>
> The throttle block is intended for software only scenarios, in which
> you want to limit the rate at which your CPU gets called to make
> computations. The throttle block simply invokes a call to sleep to
> artificially "throttle" the CPU usage. It is not related to the
> contextual sample rate of the underlying stream of data. Using a
> throttle block with hardware can cause unintended issues where you
> can't keep up with the rate of the hardware.
>
> For example, I could record data to a file from a radio with a sample
> rate of 1 Msps. If I play back that file and plot it in GNU Radio, I
> could use a throttle with any rate I want to limit CPU usage, but the
> underlying sample rate of that data will always be 1 Msps. The rate of
> CPU usage and the underlying sample rate of data are not coupled.
>
> Richard
>
>
>
> On Thu, May 29, 2025 at 10:57 AM aardric via GNU Radio, the Free &
> Open-Source Toolkit for Software Radio <discuss-gnuradio@gnu.org> wrote:
>
> Hi,
>
> Could someone please confirm my understanding that the sample
> rate in
> the attached flow graph will be determined by the active path of the
> second (from left) selector block and NOT the throttle block (that
> is,
> if throttle not selected)? This would be consistent with the block
> documentation for the selector block on the wiki.
>
>
> Rick
>

Re: sample rate with selector and throttle blocks

Hello,

TLDR: If you are using hardware in your flowgraph, which I think you are, then you should not include a throttle block. Only use throttle blocks in flowgraphs with no hardware limitations (i.e. reading from files or generating synthetic data on the fly).

The throttle block is intended for software only scenarios, in which you want to limit the rate at which your CPU gets called to make computations. The throttle block simply invokes a call to sleep to artificially "throttle" the CPU usage. It is not related to the contextual sample rate of the underlying stream of data. Using a throttle block with hardware can cause unintended issues where you can't keep up with the rate of the hardware.

For example, I could record data to a file from a radio with a sample rate of 1 Msps. If I play back that file and plot it in GNU Radio, I could use a throttle with any rate I want to limit CPU usage, but the underlying sample rate of that data will always be 1 Msps. The rate of CPU usage and the underlying sample rate of data are not coupled.

Richard

On Thu, May 29, 2025 at 10:57 AM aardric via GNU Radio, the Free & Open-Source Toolkit for Software Radio <discuss-gnuradio@gnu.org> wrote:

Hi,

Could someone please confirm my understanding that the sample rate in
the attached flow graph will be determined by the active path of the
second (from left) selector block and NOT the throttle block (that is,
if throttle not selected)? This would be consistent with the block
documentation for the selector block on the wiki.

Rick

Re: required c++ language standard

Johannes Demel <jdemel@gnuradio.org> writes:

> Regarding minimum versions. My current approach would be to set these to a
> version that works with the oldest still supported distro.
> I'd consider Ubuntu 20.04 to be the oldest, but in a few days, after 31.
> May 2025, it'll be Ubuntu 22.04.
> I know some distros offer longer support. Usually this comes with some kind
> of service subscription.
> Thus, for VOLK I'd set the minimum to versions that are still around and
> older versions may work by changing the minimum checks. Or they may not.

I don't think it's reasonable to have a list of distributions and to
dismiss the rest of the world. The target should be "any reasonable
mostly-POSIX system that is not very out of date", which notably
includes systems that are not GNU/Linux.

That doesn't really change the discussion much, as there is still "what
is too old". I agree with your implied point that LTS systems
especially those that tend to be super long term with support contracts
are not a reasonable expectation for Free Software.

Today, I'd say gcc10 is the oldest compiler that's reasonable for a
system to have, and that projects should not require newer without a
good reason.

sample rate with selector and throttle blocks

Hi,

Could someone please confirm my understanding that the sample rate in
the attached flow graph will be determined by the active path of the
second (from left) selector block and NOT the throttle block (that is,
if throttle not selected)? This would be consistent with the block
documentation for the selector block on the wiki.

Rick

Re: required c++ language standard

Hey everyone,

CMake can be a journey. Also, there's no good source of "how to CMake today". Thus, the Internet might provide help from varying times and different guidelines. Further, later CMake might require you to do things differently.

Currently, I'd expect a project to configure a minimum version (C++17 in our case) but later version should work as well.

Regarding minimum versions. My current approach would be to set these to a version that works with the oldest still supported distro.

I'd consider Ubuntu 20.04 to be the oldest, but in a few days, after 31. May 2025, it'll be Ubuntu 22.04.

I know some distros offer longer support. Usually this comes with some kind of service subscription.

Thus, for VOLK I'd set the minimum to versions that are still around and older versions may work by changing the minimum checks. Or they may not. It's a hint for contributions on what to expect.

Also, if you need to lower minimum versions, you need to know what you're doing.

Why this lengthy explanation?

Expect the minimum C version to be bumped soon to give contributors the opportunity to enjoy later language features.

Cheers

Johannes

Marcus Müller <mmueller@gnuradio.org> schrieb am Di., 20. Mai 2025, 20:45:

>Hi Greg,

better a brief reply than a late one:

On 5/19/25 5:09 PM, Greg Troxel wrote:
> It would be nice to have something easily found by a human,

agreed, but on the scale of "someone needs to know about this" and "it would be bad if
documentation goes out of sync with the implementation", setting the C++17 standard is
something that can really be left up to code.

The problem only arises if you **externally** try to force a C++ standard. If you don't do
that, then it just works. And you'll have a hard time finding a pre-C++17 compiler,
anyways, on a modern Linux.

So, I hope you understand that this is kind of low priority.

> When packaging, I like
> to align the package config files to the upstream documented
> requirements, rather than fiddling until it builds, to make it more
> likely it will be ok on some other system.

Then simply don't try to externally set C++ standard. A C++ CMake project that needs
anything newer than C++03 typically sets that itself.

> In theory I know that, but I couldn't find it in the cmake output.
> (It's also a general bug of cmake to hide build lines by default :-(
> which makes this harder.)

Seriously, I'm afraid this is a target-specific problem :) again, if you don't try to
force your compiler settings on a project in a nonstandard way, it'll just work :)

> How does building gr-osmosdr work? I don't see that it requires C++17
> (because it's in C++11 itself), but if the compiler isn't in C++17 mode
> it will object to gnuradio's headers.

CMake. When you declare a dependency on another CMake project, that imports the compiler
capabilities needed by the dependency when applicable. This all just works.

> So I think I need to in our "buildlink" file (that you include when you
> want to link against stomething) for GNU Radio add a setting to force
> c++17 mode.

That sounds like a reinvention of CMake config files and those are already a reinvention
of pkg-config .pc files – both of which GNU Radio exports, because they are well-supported
standards!
Does pkgsrc not support any of these standard mechanism?

> My cmake output follows, and I don't see about testing if the compiler
supports C++17.

I'm afraid GNU Radio is in no way different to any of the tens of thousand other
CMake-using projects out there; you'll have to deal with that as packager!

Best regards,
Marcus

Saturday, May 24, 2025

No color on buttons

I tried this one before but no answers so I'm trying again.

I'm trying to display a Toggle Button with color. I can select the colors but the button stays gray.

This problem occurred when I upgraded to 3.10.5.1 from 3.9.

There must be something missing – what is it?

Jim

Virus-free.www.avg.com

Friday, May 23, 2025

Re: GSoC FT8/WSPR OOT Module

Hi Daniel,
super happy to have you as mentee :)

Best,
Marcus

On 5/23/25 9:39 PM, Daniel Paul wrote:
> Hello everyone!
>
> My name is Daniel Paul and I'll be working with Marcus and Wylie (my mentors) on a GSoC
> project this summer. My project is to create a FT8/WSPR OOT Module that'll benefit the
> amateur radio community. If you want to follow along check out the blog I'll be posting on
> weekly: https://paulda1.github.io/blog/ <https://paulda1.github.io/blog/>
>
> Thank you and can't wait to get involved!
>
> Best,
> Daniel
>
> P.S. Please shoot me an email at danielpaul1221@gmail.com
> <mailto:danielpaul1221@gmail.com> if you have any questions or want to just chat - I'm
> always excited to learn about what you're doing :)
>

GSoC FT8/WSPR OOT Module

Hello everyone!

My name is Daniel Paul and I'll be working with Marcus and Wylie (my mentors) on a GSoC project this summer. My project is to create a FT8/WSPR OOT Module that'll benefit the amateur radio community. If you want to follow along check out the blog I'll be posting on weekly: https://paulda1.github.io/blog/

Thank you and can't wait to get involved!

Best,

Daniel

P.S. Please shoot me an email at danielpaul1221@gmail.com if you have any questions or want to just chat - I'm always excited to learn about what you're doing :)

Tuesday, May 20, 2025

Re: required c++ language standard

>Hi Greg,

better a brief reply than a late one:

On 5/19/25 5:09 PM, Greg Troxel wrote:
> It would be nice to have something easily found by a human,

agreed, but on the scale of "someone needs to know about this" and "it would be bad if
documentation goes out of sync with the implementation", setting the C++17 standard is
something that can really be left up to code.

The problem only arises if you **externally** try to force a C++ standard. If you don't do
that, then it just works. And you'll have a hard time finding a pre-C++17 compiler,
anyways, on a modern Linux.

So, I hope you understand that this is kind of low priority.

> When packaging, I like
> to align the package config files to the upstream documented
> requirements, rather than fiddling until it builds, to make it more
> likely it will be ok on some other system.

Then simply don't try to externally set C++ standard. A C++ CMake project that needs
anything newer than C++03 typically sets that itself.

> In theory I know that, but I couldn't find it in the cmake output.
> (It's also a general bug of cmake to hide build lines by default :-(
> which makes this harder.)

Seriously, I'm afraid this is a target-specific problem :) again, if you don't try to
force your compiler settings on a project in a nonstandard way, it'll just work :)

> How does building gr-osmosdr work? I don't see that it requires C++17
> (because it's in C++11 itself), but if the compiler isn't in C++17 mode
> it will object to gnuradio's headers.

CMake. When you declare a dependency on another CMake project, that imports the compiler
capabilities needed by the dependency when applicable. This all just works.

> So I think I need to in our "buildlink" file (that you include when you
> want to link against stomething) for GNU Radio add a setting to force
> c++17 mode.

That sounds like a reinvention of CMake config files and those are already a reinvention
of pkg-config .pc files – both of which GNU Radio exports, because they are well-supported
standards!
Does pkgsrc not support any of these standard mechanism?

> My cmake output follows, and I don't see about testing if the compiler
supports C++17.

I'm afraid GNU Radio is in no way different to any of the tens of thousand other
CMake-using projects out there; you'll have to deal with that as packager!

Best regards,
Marcus

NEWSDR on May 29-30 at WPI in Worcester, MA (next week!)

We would like to announce the 15th annual New England Workshop on Software Defined Radio (NEWSDR) event on Friday May 30, to be hosted in-person at Worcester Polytechnic Institute (WPI), in Worcester, Massachusetts, USA. There will also be a set of tutorials and workshops on the evening of Thursday May 29.

https://newsdr.org/workshops/newsdr-2025/

There will be presentations on Friday May 30 from people at MIT, Eurecom, UMass-Boston, UMass-Dartmouth, DeepSig, WPI, and MIT Haystack Observatory, in addition to several tutorials during the evening of Thursday May 29 from Eurecom / Northeastern University, Pi-Radio, and National Instruments.

We are very excited and honored to have as our 2025 keynote speaker Professor J. Nicholas Laneman, Professor of Electrical Engineering at the University of Notre Dame and the Director of SpectrumX, an NSF Spectrum Innovation Center.

The event is free to attend, but advanced registration is required. Please see the link below.

https://docs.google.com/forms/d/e/1FAIpQLSdwb_PunhWMBG-d8x-3TMU1nK8ff5blA3OL2wF58qkYF-50FQ/viewform?pli=1

If you are interested in presenting your research and any results related to wireless communications and/or SDR (even preliminary findings) to the community, then please consider submitting a poster abstract. Please see the link below.

https://docs.google.com/forms/d/e/1FAIpQLSeJUxZE5294_0hlmL91omHg2rBga2P-KdFF-lTnZwan8mls2A/viewform

We look forward to seeing you all at the event!!

Monday, May 19, 2025

Re: required c++ language standard

Marcus Müller <mmueller@gnuradio.org> writes:

> Dear Greg,
>
> yes, GNU Radio should only need C++17. That's defined in our
> CMakeFiles.txt, cmake/Modules/GrCompilerSettings.cmake Line 81.

Thanks - and now I know C11 is required too.

> On 5/18/25 8:50 PM, Greg Troxel wrote:
>> Is this documented and I'm just not looking in the right place?
>
> "Documented" might be a strong word for "it's hard coded in our CMake" :)

It would be nice to have something easily found by a human, from the
top-level README, that sets out the requirements, in an OS-independent
way. I had searched for this and not found it. When packaging, I like
to align the package config files to the upstream documented
requirements, rather than fiddling until it builds, to make it more
likely it will be ok on some other system.

>> Does the build system check if the compiler can support the required
>> version and add --std somehow? If not, do people think that's a bug?
>
> It does, that's a general feature of CMake.

In theory I know that, but I couldn't find it in the cmake output.
(It's also a general bug of cmake to hide build lines by default :-(
which makes this harder.)

>> Are things ok only because everybody but me is using a system where
>> the compiler is always really recent, and defaults to high language
>> standards?
>
> No, this works because unless you try to force things, the build
> system is already configured to make sure the compiler is in the right
> standards mode.

How does building gr-osmosdr work? I don't see that it requires C++17
(because it's in C++11 itself), but if the compiler isn't in C++17 mode
it will object to gnuradio's headers.

So I think I need to in our "buildlink" file (that you include when you
want to link against stomething) for GNU Radio add a setting to force
c++17 mode.

My cmake output follows, and I don't see about testing if the compiler
supports C++17.

===> Configuring for gnuradio-core-3.10.12.0nb4
/bin/ln -sf /usr/pkg/bin/pybind11-config-3.12 /tmp/work/ham/gnuradio-core/work/.buildlink/bin/pybind11-config
=> Arrange the patched line depepending on alsa is in PKG_OPTIONS or not
=> Substitute PREFIX
=> Generating pkg-config file for builtin expat package.
=> Generating pkg-config files for builtin xz package.
=> Checking for portability problems in extracted files
-- The CXX compiler identification is GNU 10.5.0
-- The C compiler identification is GNU 10.5.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /tmp/work/ham/gnuradio-core/work/.cwrapper/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /tmp/work/ham/gnuradio-core/work/.cwrapper/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type set to Release.
-- Build date set to Mon, 19 May 2025 15:01:04Z.
-- Found Git: /usr/pkg/bin/git
-- Found Boost: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/cmake/Boost-1.87.0/BoostConfig.cmake (found suitable version "1.87.0", minimum required is "1.69") found components: date_time program_options system regex thread unit_test_framework
--
-- Configuring testing-support support...
-- Dependency Boost_UNIT_TEST_FRAMEWORK_FOUND = 1
-- Disabling testing-support support.
-- Override with -DENABLE_TESTING=ON/OFF
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_WARN_SIGN_COMPARE
-- Performing Test HAVE_WARN_SIGN_COMPARE - Success
-- Performing Test HAVE_WARN_ALL
-- Performing Test HAVE_WARN_ALL - Success
-- Performing Test HAVE_WARN_NO_UNINITIALIZED
-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
-- Performing Test HAVE_WARN_IGNORED_QUALIFIERS
-- Performing Test HAVE_WARN_IGNORED_QUALIFIERS - Success
-- Performing Test HAVE_WARN_CAST_QUAL
-- Performing Test HAVE_WARN_CAST_QUAL - Success
-- Compiler Version: gcc (nb2 20230710) 10.5.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /tmp/work/ham/gnuradio-core/work/.cwrapper/bin/gcc:::-DNDEBUG -O2 -pthread -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/portaudio2 -I/usr/pkg/include/cppunit -DSPDLOG_FMT_EXTERNAL -I/usr/pkg/include/python3.12 -I/usr/X11R7/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wignored-qualifiers -Wcast-qual
/tmp/work/ham/gnuradio-core/work/.cwrapper/bin/c++:::-DNDEBUG -O2 -pthread -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/portaudio2 -I/usr/pkg/include/cppunit -DSPDLOG_FMT_EXTERNAL -I/usr/pkg/include/python3.12 -I/usr/X11R7/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/harfbuzz -I/usr/X11R7/include/libdrm -pthread -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wignored-qualifiers -Wcast-qual
-- ADDING PERF COUNTERS
CMake Warning at CMakeLists.txt:204 (message):
GR_BASH_COMPLETIONS_DIR is not defined

CMake Warning at CMakeLists.txt:218 (message):
GR_ZSH_COMPLETIONS_DIR is not defined

CMake Warning at CMakeLists.txt:232 (message):
GR_FISH_COMPLETIONS_DIR is not defined

-- User set python executable /usr/pkg/bin/python3.12
-- Found PythonInterp: /usr/pkg/bin/python3.12 (found suitable version "3.12.10", minimum required is "3.7.2")
-- Found PythonLibs: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libpython3.12.so (found suitable exact version "3.12.10")
-- Python checking for packaging - found
-- Python checking for numpy - found
-- Python checking for pygccxml - found
-- Found PythonInterp: /usr/pkg/bin/python3.12 (found suitable version "3.12.10", minimum required is "3.7")
-- Found PythonLibs: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libpython3.12.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/pkg/lib/python3.12/site-packages/pybind11/include (found version "2.13.6")
--
-- Configuring python-support support...
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency PACKAGING_FOUND = TRUE
-- Dependency pybind11_FOUND = 1
-- Dependency NUMPY_FOUND = TRUE
-- Enabling python-support support.
-- Override with -DENABLE_PYTHON=ON/OFF
--
-- Configuring VOLK support...
-- Found Volk: Volk::volk
-- Found VOLK:
-- * Version: 3.2.0
-- * Libraries: Volk::volk
-- * Includes: /tmp/work/ham/gnuradio-core/work/.buildlink/include
-- Not using additional GNU Radio native architecture optimizations.
-- Performing Test HAVE_CX_LIMITED_RANGE
-- Performing Test HAVE_CX_LIMITED_RANGE - Success
-- Performing Test HAVE_WNO_UNUSED_CMD_LINE_ARG
-- Performing Test HAVE_WNO_UNUSED_CMD_LINE_ARG - Success
-- Found PkgConfig: /tmp/work/ham/gnuradio-core/work/.tools/bin/pkg-config (found version "2.4.3")
-- Checking for module 'gmp'
-- Found gmp, version 6.3.0
-- Found GMP: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libgmpxx.so
-- Using GMP.
-- Found MPLIB: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libgmpxx.so
--
-- Configuring post-install support...
-- Disabling post-install support.
-- Override with -DENABLE_POSTINSTALL=ON/OFF
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find MathJax2 (missing: MATHJAX2_JS_PATH)
--
-- Configuring doxygen support...
-- Dependency DOXYGEN_FOUND = NO
-- Disabling doxygen support.
-- Override with -DENABLE_DOXYGEN=ON/OFF
--
-- Configuring man-pages support...
-- Disabling man-pages support.
-- Override with -DENABLE_MANPAGES=ON/OFF
-- Using GMP.
-- Looking for C++ include sys/types.h
-- Looking for C++ include sys/types.h - found
-- Looking for C++ include sys/mman.h
-- Looking for C++ include sys/mman.h - found
-- Looking for C++ include sys/ipc.h
-- Looking for C++ include sys/ipc.h - found
-- Looking for C++ include sys/shm.h
-- Looking for C++ include sys/shm.h - found
-- Looking for C++ include signal.h
-- Looking for C++ include signal.h - found
-- Performing Test HAVE_SIGACTION
-- Performing Test HAVE_SIGACTION - Success
-- Performing Test HAVE_SYSCONF
-- Performing Test HAVE_SYSCONF - Success
-- Performing Test HAVE_GETPAGESIZE
-- Performing Test HAVE_GETPAGESIZE - Success
-- Performing Test HAVE_PTHREAD_SIGMASK
-- Performing Test HAVE_PTHREAD_SIGMASK - Success
-- Performing Test HAVE_CREATEFILEMAPPING
-- Performing Test HAVE_CREATEFILEMAPPING - Failed
-- Performing Test HAVE_SHM_OPEN
-- Performing Test HAVE_SHM_OPEN - Success
-- Performing Test HAVE_SINCOS
-- Performing Test HAVE_SINCOS - Success
-- Performing Test HAVE_SINCOSF
-- Performing Test HAVE_SINCOSF - Success
-- Performing Test HAVE_SINF
-- Performing Test HAVE_SINF - Success
-- Performing Test HAVE_COSF
-- Performing Test HAVE_COSF - Success
-- Performing Test HAVE_MMAP
-- Performing Test HAVE_MMAP - Success
-- Performing Test HAVE_PTHREAD_SETSCHEDPARAM
-- Performing Test HAVE_PTHREAD_SETSCHEDPARAM - Success
-- Performing Test HAVE_SCHED_SETSCHEDULER
-- Performing Test HAVE_SCHED_SETSCHEDULER - Success
-- Found Threads: TRUE
--
-- Configuring gnuradio-runtime support...
-- Dependency Boost_FOUND = TRUE
-- Dependency PYTHONINTERP_FOUND = TRUE
-- Dependency MPLIB_FOUND = TRUE
-- Dependency spdlog_FOUND = 1
-- Dependency Volk_FOUND = 1
-- Enabling gnuradio-runtime support.
-- Override with -DENABLE_GNURADIO_RUNTIME=ON/OFF
--
-- Configuring common-precompiled-headers support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency GR_CMAKE_HAS_PCH =
-- Disabling common-precompiled-headers support.
-- Override with -DENABLE_COMMON_PCH=ON/OFF
--
-- Configuring gr-ctrlport support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Enabling gr-ctrlport support.
-- Override with -DENABLE_GR_CTRLPORT=ON/OFF
-- Checking for module 'thrift'
-- Package 'thrift' not found
-- thrift looking for version 0.13
-- Binary 'thrift' not found.
-- Looking for C++ include sys/resource.h
-- Looking for C++ include sys/resource.h - found
-- Checking for module 'libunwind'
-- Package 'libunwind' not found
-- Found libunwind
-- Loading build date Mon, 19 May 2025 15:01:04Z into constants...
-- Loading version 3.10.12.0 into constants...
-- TRY_SHM_VMCIRCBUF set to ON.
--
-- Python checking for PyYAML >= 3.11 - found
-- Python checking for mako >= 1.1.0 - found
-- Python checking for pygobject >= 2.28.6 - found
-- Python checking for Gtk (GI) >= 3.10.8 - found
-- Python checking for Cairo (GI) >= 1.0 - found
-- Python checking for PangoCairo (GI) >= 1.0 - found
-- Python checking for numpy - found
-- Python checking for jsonschema - found
--
-- Configuring gnuradio-companion support...
-- Dependency ENABLE_PYTHON = ON
-- Dependency PYYAML_FOUND = TRUE
-- Dependency MAKO_FOUND = TRUE
-- Dependency PYGI_FOUND = TRUE
-- Dependency GTK_GI_FOUND = TRUE
-- Dependency CAIRO_GI_FOUND = TRUE
-- Dependency PANGOCAIRO_GI_FOUND = TRUE
-- Dependency NUMPY_FOUND = TRUE
-- Disabling gnuradio-companion support.
-- Override with -DENABLE_GRC=ON/OFF
-- Checking for module 'sndfile'
-- Found sndfile, version 1.2.2
-- Found SNDFILE: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libsndfile.so
--
-- Configuring gr-blocks support...
-- Dependency Boost_FOUND = TRUE
-- Enabling gr-blocks support.
-- Override with -DENABLE_GR_BLOCKS=ON/OFF
-- Looking for C++ include io.h
-- Looking for C++ include io.h - not found
-- Found GSL: /tmp/work/ham/gnuradio-core/work/.buildlink/include (found version "2.8")
--
-- Configuring gr-fec support...
-- Disabling gr-fec support.
-- Override with -DENABLE_GR_FEC=ON/OFF
-- Checking for module 'fftw3f >= 3.0'
-- Found fftw3f, version 3.3.10
-- Found FFTW3f: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libfftw3f.so
--
-- Configuring gr-fft support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency FFTW3f_FOUND = TRUE
-- Enabling gr-fft support.
-- Override with -DENABLE_GR_FFT=ON/OFF
--
-- Configuring gr-filter support...
-- Dependency Boost_FOUND = TRUE
-- Enabling gr-filter support.
-- Override with -DENABLE_GR_FILTER=ON/OFF
-- Python checking for pyqtgraph - found
-- Python checking for scipy - found
--
-- Configuring gr-analog support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Enabling gr-analog support.
-- Override with -DENABLE_GR_ANALOG=ON/OFF
--
-- Configuring gr-digital support...
-- Dependency Boost_FOUND = TRUE
-- Disabling gr-digital support.
-- Override with -DENABLE_GR_DIGITAL=ON/OFF
--
-- Configuring gr-dtv support...
-- Disabling gr-dtv support.
-- Override with -DENABLE_GR_DTV=ON/OFF
--
-- Configuring gr-audio support...
-- Enabling gr-audio support.
-- Override with -DENABLE_GR_AUDIO=ON/OFF
-- Checking for module 'jack'
-- Found jack, version 1.9.21
-- Found jack: /tmp/work/ham/gnuradio-core/work/.buildlink/lib/libjack.so
-- Looking for C++ include AudioUnit/AudioUnit.h
-- Looking for C++ include AudioUnit/AudioUnit.h - not found
-- Looking for C++ include AudioToolbox/AudioToolbox.h
-- Looking for C++ include AudioToolbox/AudioToolbox.h - not found
-- Checking for module 'portaudio-2.0'
-- Found portaudio-2.0, version 19
-- Performing Test PORTAUDIO2_FOUND
-- Performing Test PORTAUDIO2_FOUND - Success
-- Found PORTAUDIO: /usr/pkg/include/portaudio2
--
-- Configuring gr-channels support...
-- Disabling gr-channels support.
-- Override with -DENABLE_GR_CHANNELS=ON/OFF
--
-- Configuring gr-pdu support...
-- Disabling gr-pdu support.
-- Override with -DENABLE_GR_PDU=ON/OFF
-- Could NOT find libiio (missing: libiio_LIBRARY libiio_INCLUDE_DIR)
-- Could NOT find libad9361 (missing: libad9361_LIBRARY libad9361_INCLUDE_DIR)
--
-- Configuring gr-iio support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency libiio_FOUND = FALSE
-- Disabling gr-iio support.
-- Override with -DENABLE_GR_IIO=ON/OFF
-- Python checking for PyQt5 - found
-- Checking for module 'Qt5Qwt6'
-- Package 'Qt5Qwt6' not found
--
-- Configuring gr-qtgui support...
-- Dependency QT_FOUND = 1
-- Dependency QWT_FOUND = FALSE
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency PYQT5_FOUND = TRUE
-- Disabling gr-qtgui support.
-- Override with -DENABLE_GR_QTGUI=ON/OFF
--
-- Configuring gr-trellis support...
-- Disabling gr-trellis support.
-- Override with -DENABLE_GR_TRELLIS=ON/OFF
-- Found UHD: /usr/pkg/lib/libuhd.so (Required is at least version "3.9.7")
-- Python checking for PyQt5 - found
--
-- Configuring gr-uhd support...
-- Dependency Boost_FOUND = TRUE
-- Dependency UHD_FOUND = TRUE
-- Disabling gr-uhd support.
-- Override with -DENABLE_GR_UHD=ON/OFF
--
-- Configuring gr-uhd UHD 4.0 RFNoC support...
-- Dependency ENABLE_GR_UHD = OFF
-- Dependency UHD_FOUR_POINT_OH_RFNOC = TRUE
-- Disabling gr-uhd UHD 4.0 RFNoC support.
-- Override with -DENABLE_UHD_RFNOC=ON/OFF
-- Python checking for Mako >= 1.1.0 - found
-- Python checking for click - found
--
-- Configuring gr-utils support...
-- Dependency ENABLE_PYTHON = ON
-- Dependency MAKO_FOUND = TRUE
-- Disabling gr-utils support.
-- Override with -DENABLE_GR_UTILS=ON/OFF
--
-- Configuring gr_modtool support...
-- Dependency ENABLE_PYTHON = ON
-- Dependency CLICK_FOUND = TRUE
-- Disabling gr_modtool support.
-- Override with -DENABLE_GR_MODTOOL=ON/OFF
--
-- Configuring gr_blocktool support...
-- Dependency ENABLE_PYTHON = ON
-- Disabling gr_blocktool support.
-- Override with -DENABLE_GR_BLOCKTOOL=ON/OFF
-- Could NOT find SDL (missing: SDL_LIBRARY SDL_INCLUDE_DIR)
--
-- Configuring gr-video-sdl support...
-- Dependency SDL_FOUND = FALSE
-- Disabling gr-video-sdl support.
-- Override with -DENABLE_GR_VIDEO_SDL=ON/OFF
--
-- Configuring gr-vocoder support...
-- Disabling gr-vocoder support.
-- Override with -DENABLE_GR_VOCODER=ON/OFF
--
-- Configuring gr-wavelet support...
-- Dependency GSL_FOUND = TRUE
-- Disabling gr-wavelet support.
-- Override with -DENABLE_GR_WAVELET=ON/OFF
-- Checking for module 'libzmq'
-- Package 'libzmq' not found
-- Could NOT find ZeroMQ (missing: ZEROMQ_LIBRARIES)
--
-- Configuring gr-zeromq support...
-- Dependency ZEROMQ_FOUND = FALSE
-- Dependency CPPZMQ_HAS_SHUTDOWN =
-- Disabling gr-zeromq support.
-- Override with -DENABLE_GR_ZEROMQ=ON/OFF
--
-- Configuring gr-network support...
-- Dependency Boost_FOUND = TRUE
-- Disabling gr-network support.
-- Override with -DENABLE_GR_NETWORK=ON/OFF
--
-- Configuring gr-soapy support...
-- Dependency SoapySDR_FOUND = 1
-- Disabling gr-soapy support.
-- Override with -DENABLE_GR_SOAPY=ON/OFF
--
-- ######################################################
-- # Gnuradio enabled components
-- ######################################################
-- * python-support
-- * gnuradio-runtime
-- * gr-ctrlport
-- * gr-blocks
-- * gr-fft
-- * gr-filter
-- * gr-analog
-- * gr-audio
-- * * oss
-- * * jack
-- * * portaudio
--
-- ######################################################
-- # Gnuradio disabled components
-- ######################################################
-- * testing-support
-- * post-install
-- * doxygen
-- * man-pages
-- * common-precompiled-headers
-- * gnuradio-companion
-- * gr-fec
-- * gr-digital
-- * gr-dtv
-- * gr-channels
-- * gr-pdu
-- * gr-iio
-- * gr-qtgui
-- * gr-trellis
-- * gr-uhd
-- * gr-uhd UHD 4.0 RFNoC
-- * gr-utils
-- * gr_modtool
-- * gr_blocktool
-- * gr-video-sdl
-- * gr-vocoder
-- * gr-wavelet
-- * gr-zeromq
-- * gr-network
-- * gr-soapy
--
-- Using install prefix: /usr/pkg
-- Building for version: 3.10.12.0 / 3.10.12
-- Configuring done (15.7s)
-- Generating done (0.2s)
CMake Warning:
Manually-specified variables were not used by the project:

FETCHCONTENT_FULLY_DISCONNECTED
Python3_EXECUTABLE
Python3_INCLUDE_DIR
Python_EXECUTABLE
Python_INCLUDE_DIR

-- Build files have been written to: /tmp/work/ham/gnuradio-core/work/gnuradio-3.10.12.0/cmake-pkgsrc-build

Re: required c++ language standard

Dear Greg,

yes, GNU Radio should only need C++17. That's defined in our CMakeFiles.txt,
cmake/Modules/GrCompilerSettings.cmake Line 81.

On 5/18/25 8:50 PM, Greg Troxel wrote:
> Is this documented and I'm just not looking in the right place?

"Documented" might be a strong word for "it's hard coded in our CMake" :)

> What C++ language variant is GNU Radio 3.10.12 written in?

C++17

> Does the build system check if the compiler can support the required
> version and add --std somehow? If not, do people think that's a bug?

It does, that's a general feature of CMake.

> Are things ok only because everybody but me is using a system where
> the compiler is always really recent, and defaults to high language
> standards?

No, this works because unless you try to force things, the build system is already
configured to make sure the compiler is in the right standards mode.

Best regards,
Marcus

NEWSDR on May 29-30, at WPI in Worcester, Massachusetts

Re: Making fundemental OOT source block mistakes?

Hi Robert,

It seems that your OOT block is already enforcing a sample rate on its own, so you don't need to use a throttle in your flowgraph.

Actually, as you noticed, you should not use one.
In your case the throttle, in its throttling operation, blocks the sample stream long enough for samples to fill in the output buffer of your block and have it stop running its work function.

Apart from that, it seems to work :)

Cyrille

Le 18/05/2025 à 23:30, Robert Heerekop a écrit :

My objective is to measure a phase shift between a demodulated FM-audio tone and an external 500Hz clock.

A simple C++ OOT source module 'gptest' reads the status of an input pin (connected to an external 500Hz clock) and copies the state to a gpio monitor-output pin (to monitor the behaviour with an oscillosope).

In the flowgraph the 500Hz input signal (green) goes via a throttle to a null sink.
If the throttle is bypassed the monitor-output signal (yellow) shows by that the OOT source module is fully able to process the 500Hz clock signal.
However, if the throttle is enabled, the monitor-output signal shows that the OOT source module skips most source clock cycles.
This also happens if the input clock signal is e.g. turned into a float and a filter is applied.

My objective is to measure a phase shift between this external 500Hz clock and a demodulated FM-audio tone.
Can you comment on my approach and/or explain how to fully process the 500Hz clock signal?

Thanks in advance, I learn from your feedback!

Sunday, May 18, 2025

Making fundemental OOT source block mistakes?

/* -*- c++ -*- */
/*
* Copyright 2025 MyName.
* This is a bear minimum test/learn OOT source module which reads the status of a input pin and
* copies the state the a gpio output pin. The enables me to learn and figure out if this
* is a right way in working towards a solution to measure a phase shift between a demodulated
* FM-audio tone and an external 500Hz clock.
*
* SPDX-License-Identifier: GPL-3.0-or-later
*/

#include "gptest_impl.h"
#include <gnuradio/io_signature.h>

#include <gpiod.hpp> //gpio hardware driver and settings for RaspberryPi5
#ifndef CONSUMER
#define CONSUMER "Consumer"
#endif
const char* chipname_B = "gpiochip0";
const int gpio_write_pin = 27; // a logic 1 or 0 is fed to the gpio input pin27
const int gpio_read_pin = 17; // an output signal is fed to gpio output pin17 to which a LED is connected
gpiod_chip* global_chip_B = nullptr;
gpiod_line* global_write_line_B = nullptr;
gpiod_line* global_read_line_B = nullptr;

namespace gr {
namespace customModule {

using output_type = int;
gptest::sptr gptest::make() { return gnuradio::make_block_sptr<gptest_impl>(); }

/*
* The private constructor
*/
gptest_impl::gptest_impl()
: gr::sync_block("gptest",
gr::io_signature::make(0, 0, 0),
gr::io_signature::make(
1 /* min outputs */, 1 /*max outputs */, sizeof(output_type)))
{
}

/*
* Our virtual destructor.
*/
gptest_impl::~gptest_impl() {}

bool gptest_impl::start() {
std::cout << "OOT module started" << std::endl;
gpiod_chip* chip = gpiod_chip_open_by_name(chipname_B); // Open GPIO chip
if (!chip) {
std::cout << "Error opening chip" << std::endl;
}
else {
std::cout << "Succesfully opened chip" << std::endl;
}
gpiod_line* write_line = gpiod_chip_get_line(chip, gpio_write_pin); // Initialize output line
if (!write_line) {
std::cout << "Error setting output line" << std::endl;
gpiod_chip_close(chip);
}
else {
std::cout << "Succesfully set output line" << std::endl;
}
if (gpiod_line_request_output(write_line, CONSUMER, 0) < 0) { // Request output mode
std::cout << "Request line as output failed\n" << std::endl;
gpiod_line_release(write_line);
gpiod_chip_close(chip);
}
else {
std::cout << "Succesfully requested line as output" << std::endl;
}
gpiod_line* read_line = gpiod_chip_get_line(chip, gpio_read_pin); // Initialize input line
if (!read_line) {
std::cout << "Error setting input line" << std::endl;
gpiod_chip_close(chip);
}
else {
std::cout << "Succesfully set input line" << std::endl;
}
if (gpiod_line_request_input(read_line, CONSUMER) < 0) { // Request input mode
std::cout << "Request line as input failed\n" << std::endl;
gpiod_line_release(read_line);
gpiod_chip_close(chip);
}
else {
std::cout << "Succesfully requested line as input" << std::endl;
}
int ret = gpiod_line_set_value(write_line, 1); // Set LED on
if (ret < 0) {
std::cout << "Set line output failed\n" << std::endl;
}
else {
std::cout << "Succesfully set lineoutput" << std::endl;
}
global_chip_B = chip; // Assign the value of `chip` to the global variable
global_write_line_B = write_line; // Assign the value of `write_line` to the global variable
global_read_line_B = read_line; // Assign the value of `read_line` to the global variable
return true; // Return true if initialization is successful
}

bool gptest_impl::stop() {
std::cout << "OOT module stopped, see you next time!" << std::endl;
gpiod_chip* chip = global_chip_B;
gpiod_line* write_line = global_write_line_B;
gpiod_line* read_line = global_read_line_B;

int ret = gpiod_line_set_value(write_line, 0); // Set LED off
if (ret < 0) {
perror("Set line output failed\n");
}
std::cout << "Start to release output line" << std::endl; // Cleanup output line
gpiod_line_release(write_line);
std::cout << "Outpunt line released " << std::endl;

std::cout << "Start to release input line" << std::endl; // Cleanup input line
gpiod_line_release(read_line);
std::cout << "Input line released " << std::endl;

std::cout << "Start to close chip line" << std::endl;
gpiod_chip_close(chip);
std::cout << "Chip closed" << std::endl;
return true; // Return true if de-initialization is successful
}

int gptest_impl::work(int noutput_items,
gr_vector_const_void_star& input_items,
gr_vector_void_star& output_items)
{
gpiod_line* write_line = global_write_line_B;
gpiod_line* read_line = global_read_line_B;

auto out = static_cast<output_type*>(output_items[0]);

for (int index = 0; index < noutput_items; index++) { // Here the action the the module takes place !

int state = gpiod_line_get_value(read_line);
int ret = gpiod_line_set_value(write_line, state); // the status of the input gpio is copied to the output gpio
if (ret < 0) {
std::cout << "Set line output failed" << std::endl;
}
if (state == 0) { out[index] = 0x00; }
else{ out[index] = 0xFF; }

}
return noutput_items; // Tell runtime system how many output items we produced.
}

} /* namespace customModule */
} /* namespace gr */

My objective is to measure a phase shift between a demodulated FM-audio tone and an external 500Hz clock.

A simple C++ OOT source module 'gptest' reads the status of an input pin (connected to an external 500Hz clock) and copies the state to a gpio monitor-output pin (to monitor the behaviour with an oscillosope).

In the flowgraph the 500Hz input signal (green) goes via a throttle to a null sink.
If the throttle is bypassed the monitor-output signal (yellow) shows by that the OOT source module is fully able to process the 500Hz clock signal.
However, if the throttle is enabled, the monitor-output signal shows that the OOT source module skips most source clock cycles.
This also happens if the input clock signal is e.g. turned into a float and a filter is applied.

My objective is to measure a phase shift between this external 500Hz clock and a demodulated FM-audio tone.
Can you comment on my approach and/or explain how to fully process the 500Hz clock signal?

Thanks in advance, I learn from your feedback!

Re: Message Strobe and SDR problem

Hi,

I have created another version, BPSK_test_02_4, which transmits a packet containing a pair of random bytes every second. I log the generated pairs (01_byte_tx_log.csv) and the received pairs (06_byte_rx_log.csv) and add CRC. This allows me to match pairs and accurately identify the delay and buffering of my packets in the receiver block (matched_bytes.csv). I assume that I lost many pairs due to imperfections in my project, but the delay and data buffering are noticeable and interesting.

Main github link: https://github.com/yabool2001/BPSK_test_02_4/

Best regards,

Yabool2001

niedz., 18 maj 2025 o 13:35 Maciej Zemło <mzemlo.pl@gmail.com> napisał(a):

Hi,
Important and interesting update.
During the testing of the BPSK_test_02_3 project, I initially believed that no valid demodulation was occurring when transmitting a packet every second. However, after accidentally leaving the transmission running for a longer duration, I observed that after approximately 95 seconds, a first burst of aggregated packets appeared. Interestingly, when repeating this experiment several times, the first occurrence of the packet burst consistently appeared after the same duration of 95 seconds. This behavior suggests a systematic delay or data accumulation occurring at a specific time interval, leading to a sudden release of aggregated data packets.

Statistics Based on log files:
In the transmitter block, 470 packets containing a 1-byte payload were sent every second (01_complex_tx_bpsk_mod_log.csv - too big to view on github). In the receiver block, 306 packets were received as follows (06_byte_rx_log.csv):
- at 95.16 seconds, 23 packets were received. Then a short pause.
- at 95.66 seconds, 3 packets were received. Then a long pause.
- at 188.78 seconds, 7 packets were received. Then a short pause.
- at 189.27 seconds, 11 packets were received. Then a long pause.
- at 282.39 seconds, 32 packets were received. Then a short pause.
- at 282.89 seconds, 56 packets were received. Then a long pause.
- at 376.00 seconds, 6 packets were received. Then a short pause.
- at 376.01 seconds, 29 packets were received. Then a short pause.
- at 376.50 seconds, 54 packets were received. Then a long pause.
- at 469.62 seconds, 36 packets were received. Then a short pause.
- at 470.12 seconds, 49 packets were received. End of test.

Link to projekt https://github.com/yabool2001/BPSK_test_02_3

Best regards,
Maciek

sob., 17 maj 2025 o 14:32 Maciej Zemło <mzemlo.pl@gmail.com> napisał(a):
Hi Marcus and Adrian,

Apologies for the incorrect link to the private image. You are correct, the diagram in the README.md is the proper one. Thanks a lot for your advice.

For now, I've tried the simplest solution — adding a "Simple Squelch" block to feed the "Polyphase Clock Sync" only when a signal is present. The updated schematic is now available in the README.md of the project on GitHub:
https://github.com/yabool2001/BPSK_test_02_3

Unfortunately, it didn't help. In this configuration, the project only works with a continuous source, such as "Constant Source". If there is a better implementation for signal detection that could assist in burst transmission, I'd be grateful for your recommendation.

Now, I will also try Adrian's suggestion to implement the "Correlation Estimator" block.

Thanks again for your support!

Best regards,
Yabool2001

pon., 12 maj 2025 o 14:51 Marcus Müller <mmueller@gnuradio.org> napisał(a):
Hi Maciej,

sadly, you attached a link to a picture on
https://private-user-images.githubusercontent.com… , which is github-account-specific and
can't be used by anyone but you. But the raw URL in your Readme works,
https://github.com/user-attachments/assets/3f9eee70-811e-41be-9d43-877b2dcbb078
so I'm assuming that's the one.

What I think is wrong here is that the Polyphase Clock Sync drifts off during the pauses
between frames: it doesn't know whether it's looking at noise only or signal, and so tries
to "wildly" guess what it should do during the "noise only" periods, just to then be off
from the correct timing enough to not be able to catch up with it during the first few
symbols of each frame.

In a practical system, you'd need to first detect presence before you feed it through the
clock synchronizer.

Best regards,
Marcus

On 5/12/25 10:47 AM, Maciej Zemło wrote:
> Hi everyone,
>
> I've developed a brief demonstration project in GRC that transmits a single byte via Pluto
> using BPSK modulation. The project works well when using a "Constant Source" block that
> continuously sends the byte, but it completely fails to function with the "Message Strobe"
> block, which sends a byte every 0.5 seconds.
>
> The project is available on GitHub for further reference: https://github.com/yabool2001/
> BPSK_test_02_3 <https://github.com/yabool2001/BPSK_test_02_3>
>
> I've attached a screenshot illustrating the structure of the project, available here
> <https://private-user-
> images.githubusercontent.com/38382353/442661233-3f9eee70-811e-41be-9d43-877b2dcbb078.png?
> jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDcwMzkyNTIsIm5iZiI6MTc0NzAzODk1MiwicGF0aCI6Ii8zODM4MjM1My80NDI2NjEyMzMtM2Y5ZWVlNzAtODExZS00MWJlLTlkNDMtODc3YjJkY2JiMDc4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTEyVDA4MzU1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTg2MmQ3MjAxM2U2NDg3MmI3MzZkZGQyNGFlMzdlODdkZjlmYjRlMjc1ZDgzYzgwYmE4OGQ1ZDE5OTM2MWFjNjkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.whxllXKHs55LV7wgcRfq7BPy3oQjAiGJWUoKc-J8en8>.
>
> Could someone point me in the right direction regarding what might be going wrong here?
>
> Thanks in advance for your assistance!
>
> Best regards,
> Yabool2001
>

required c++ language standard

In pkgsrc, GNU Radio is at 3.10.12.0.

It is marked as needing a C++20 compiler, but this seems surprising.
This minute, I believe that's confused on our part, and it needs C++17.

Reading CMakeFile.txt and README and following pointers, I can't find
anything which says what C++ language variant GNU Radio is written in,
and whether the build environment needs to force that, vs letting the gr
build system test if --std=c++NN works and then adding it.

I find experimentally that building gr-osmosdr with a forced --std=c++11
fails due to things in the gnuradio headers, apparently, and with a
forced --std=c++17 it builds. I find the same thing with our
gnuradio-core package which is the normal key blocks split from
everything.

My questions:

Is this documented and I'm just not looking in the right place?

What C++ language variant is GNU Radio 3.10.12 written in?

Does the build system check if the compiler can support the required
version and add --std somehow? If not, do people think that's a bug?

Are things ok only because everybody but me is using a system where
the compiler is always really recent, and defaults to high language
standards?

Thanks
Greg

gr-osmosdr python failure

I tried to file a bug at the gitea, but it seems not to allow
registration.

In pkgsrc, we have a ham/gr-osmosdr package which is pretty
straightforward. Recently we got a report that while it builds,
importing the python module fails, unless one uses gcc12 (instead of
10). The README doesn't document a C++ language variant, but CMakeFile
is clear that it's c++11, which gcc10 supports just fine.

The symptom is:

> python3.12
Python 3.12.10 (main, May 9 2025, 12:01:51) [GCC 10.5.0] on netbsd10
Type "help", "copyright", "credits" or "license" for more information.
>>> import osmosdr
Traceback (most recent call last):
File "/usr/pkg/lib/python3.12/site-packages/osmosdr/__init__.py", line 17, in <module>
from .osmosdr_python import *
ImportError: generic_type: type "sink" referenced unknown base type "gr::hier_block2"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/pkg/lib/python3.12/site-packages/osmosdr/__init__.py", line 21, in <module>
from .osmosdr_python import *
ImportError: generic_type: type "sink" referenced unknown base type "gr::hier_block2"

So, my questions are:

is C++11 really the required standard?

is there some new code assuming a newer --std, and this only works
with gcc12 because it defaults to newer?

gnuradio itself seems to require c++20. Is this "gnuradio header
files need to be processed in c++20 mode, but they don't error if
processed in c++11 mode"?

gnuradio itself seems to require c++20. Is this "C++ ABI is a mess
and using headers that are valid c++11 with a c++11 compiler, won't
interwork with code built in c++20 mode"?

something else?

Re: Message Strobe and SDR problem

Hi,

Important and interesting update.

During the testing of the BPSK_test_02_3 project, I initially believed that no valid demodulation was occurring when transmitting a packet every second. However, after accidentally leaving the transmission running for a longer duration, I observed that after approximately 95 seconds, a first burst of aggregated packets appeared. Interestingly, when repeating this experiment several times, the first occurrence of the packet burst consistently appeared after the same duration of 95 seconds. This behavior suggests a systematic delay or data accumulation occurring at a specific time interval, leading to a sudden release of aggregated data packets.

Statistics Based on log files:
In the transmitter block, 470 packets containing a 1-byte payload were sent every second (01_complex_tx_bpsk_mod_log.csv - too big to view on github). In the receiver block, 306 packets were received as follows (06_byte_rx_log.csv):
- at 95.16 seconds, 23 packets were received. Then a short pause.
- at 95.66 seconds, 3 packets were received. Then a long pause.
- at 188.78 seconds, 7 packets were received. Then a short pause.
- at 189.27 seconds, 11 packets were received. Then a long pause.
- at 282.39 seconds, 32 packets were received. Then a short pause.
- at 282.89 seconds, 56 packets were received. Then a long pause.
- at 376.00 seconds, 6 packets were received. Then a short pause.
- at 376.01 seconds, 29 packets were received. Then a short pause.
- at 376.50 seconds, 54 packets were received. Then a long pause.
- at 469.62 seconds, 36 packets were received. Then a short pause.
- at 470.12 seconds, 49 packets were received. End of test.

Link to projekt https://github.com/yabool2001/BPSK_test_02_3

Best regards,

Maciek

sob., 17 maj 2025 o 14:32 Maciej Zemło <mzemlo.pl@gmail.com> napisał(a):

Hi Marcus and Adrian,

Apologies for the incorrect link to the private image. You are correct, the diagram in the README.md is the proper one. Thanks a lot for your advice.

For now, I've tried the simplest solution — adding a "Simple Squelch" block to feed the "Polyphase Clock Sync" only when a signal is present. The updated schematic is now available in the README.md of the project on GitHub:
https://github.com/yabool2001/BPSK_test_02_3

Unfortunately, it didn't help. In this configuration, the project only works with a continuous source, such as "Constant Source". If there is a better implementation for signal detection that could assist in burst transmission, I'd be grateful for your recommendation.

Now, I will also try Adrian's suggestion to implement the "Correlation Estimator" block.

Thanks again for your support!

Best regards,
Yabool2001

pon., 12 maj 2025 o 14:51 Marcus Müller <mmueller@gnuradio.org> napisał(a):
Hi Maciej,

sadly, you attached a link to a picture on
https://private-user-images.githubusercontent.com… , which is github-account-specific and
can't be used by anyone but you. But the raw URL in your Readme works,
https://github.com/user-attachments/assets/3f9eee70-811e-41be-9d43-877b2dcbb078
so I'm assuming that's the one.

What I think is wrong here is that the Polyphase Clock Sync drifts off during the pauses
between frames: it doesn't know whether it's looking at noise only or signal, and so tries
to "wildly" guess what it should do during the "noise only" periods, just to then be off
from the correct timing enough to not be able to catch up with it during the first few
symbols of each frame.

In a practical system, you'd need to first detect presence before you feed it through the
clock synchronizer.

Best regards,
Marcus

On 5/12/25 10:47 AM, Maciej Zemło wrote:
> Hi everyone,
>
> I've developed a brief demonstration project in GRC that transmits a single byte via Pluto
> using BPSK modulation. The project works well when using a "Constant Source" block that
> continuously sends the byte, but it completely fails to function with the "Message Strobe"
> block, which sends a byte every 0.5 seconds.
>
> The project is available on GitHub for further reference: https://github.com/yabool2001/
> BPSK_test_02_3 <https://github.com/yabool2001/BPSK_test_02_3>
>
> I've attached a screenshot illustrating the structure of the project, available here
> <https://private-user-
> images.githubusercontent.com/38382353/442661233-3f9eee70-811e-41be-9d43-877b2dcbb078.png?
> jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDcwMzkyNTIsIm5iZiI6MTc0NzAzODk1MiwicGF0aCI6Ii8zODM4MjM1My80NDI2NjEyMzMtM2Y5ZWVlNzAtODExZS00MWJlLTlkNDMtODc3YjJkY2JiMDc4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTEyVDA4MzU1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTg2MmQ3MjAxM2U2NDg3MmI3MzZkZGQyNGFlMzdlODdkZjlmYjRlMjc1ZDgzYzgwYmE4OGQ1ZDE5OTM2MWFjNjkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.whxllXKHs55LV7wgcRfq7BPy3oQjAiGJWUoKc-J8en8>.
>
> Could someone point me in the right direction regarding what might be going wrong here?
>
> Thanks in advance for your assistance!
>
> Best regards,
> Yabool2001
>

Saturday, May 17, 2025

Re: Message Strobe and SDR problem

Hi Marcus and Adrian,

Apologies for the incorrect link to the private image. You are correct, the diagram in the README.md is the proper one. Thanks a lot for your advice.

For now, I've tried the simplest solution — adding a "Simple Squelch" block to feed the "Polyphase Clock Sync" only when a signal is present. The updated schematic is now available in the README.md of the project on GitHub:
https://github.com/yabool2001/BPSK_test_02_3

Unfortunately, it didn't help. In this configuration, the project only works with a continuous source, such as "Constant Source". If there is a better implementation for signal detection that could assist in burst transmission, I'd be grateful for your recommendation.

Now, I will also try Adrian's suggestion to implement the "Correlation Estimator" block.

Thanks again for your support!

Best regards,
Yabool2001

pon., 12 maj 2025 o 14:51 Marcus Müller <mmueller@gnuradio.org> napisał(a):

Hi Maciej,

sadly, you attached a link to a picture on
https://private-user-images.githubusercontent.com… , which is github-account-specific and
can't be used by anyone but you. But the raw URL in your Readme works,
https://github.com/user-attachments/assets/3f9eee70-811e-41be-9d43-877b2dcbb078
so I'm assuming that's the one.

What I think is wrong here is that the Polyphase Clock Sync drifts off during the pauses
between frames: it doesn't know whether it's looking at noise only or signal, and so tries
to "wildly" guess what it should do during the "noise only" periods, just to then be off
from the correct timing enough to not be able to catch up with it during the first few
symbols of each frame.

In a practical system, you'd need to first detect presence before you feed it through the
clock synchronizer.

Best regards,
Marcus

On 5/12/25 10:47 AM, Maciej Zemło wrote:
> Hi everyone,
>
> I've developed a brief demonstration project in GRC that transmits a single byte via Pluto
> using BPSK modulation. The project works well when using a "Constant Source" block that
> continuously sends the byte, but it completely fails to function with the "Message Strobe"
> block, which sends a byte every 0.5 seconds.
>
> The project is available on GitHub for further reference: https://github.com/yabool2001/
> BPSK_test_02_3 <https://github.com/yabool2001/BPSK_test_02_3>
>
> I've attached a screenshot illustrating the structure of the project, available here
> <https://private-user-
> images.githubusercontent.com/38382353/442661233-3f9eee70-811e-41be-9d43-877b2dcbb078.png?
> jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDcwMzkyNTIsIm5iZiI6MTc0NzAzODk1MiwicGF0aCI6Ii8zODM4MjM1My80NDI2NjEyMzMtM2Y5ZWVlNzAtODExZS00MWJlLTlkNDMtODc3YjJkY2JiMDc4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA1MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNTEyVDA4MzU1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTg2MmQ3MjAxM2U2NDg3MmI3MzZkZGQyNGFlMzdlODdkZjlmYjRlMjc1ZDgzYzgwYmE4OGQ1ZDE5OTM2MWFjNjkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.whxllXKHs55LV7wgcRfq7BPy3oQjAiGJWUoKc-J8en8>.
>
> Could someone point me in the right direction regarding what might be going wrong here?
>
> Thanks in advance for your assistance!
>
> Best regards,
> Yabool2001
>

Friday, May 16, 2025

NEWSDR on May 29-30 at WPI in Worcester, Massachusetts

Thursday, May 15, 2025

NEWSDR on May 29-30 at WPI in Worcester, Massachusetts (Greater Boston)

Tuesday, May 13, 2025

Re: Modifying BPSK to QPSK

Richard,

I have adapted the flowgraph you have sent to transmit a file over QPSK using USRPs, instead of transmitting a random source through simulation. It is attached, I know I could probably add the AGC block as there is a real channel now. I will update with any progress and further flowgraphs. Thank you for all your help Richard I really appreciate it! The flowgraph is too big to attach but I will put the screenshot below.

Thanks,

Zach

On Tue, May 13, 2025 at 5:48 AM Richard Bell <richard.bell4@gmail.com> wrote:

Hi Zachary,

This flowgraph works. It seems the main problem was the constellation object. Go through this carefully and compare it to your previous one to understand the exact differences.

Rich

On Mon, May 12, 2025 at 6:39 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
My flowgraph attachment didn't make it to the mailing list as it was too large a file. I am compressing and attaching here again so others are able to follow the conversation.

Zach

On Fri, May 9, 2025 at 7:07 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Also, if it is helpful this is where I got the packet communications basis from, I read through this GNURadio page and used this structure for mine.
https://wiki.gnuradio.org/index.php?title=Packet_Communications_Test_Page

On Fri, May 9, 2025 at 6:55 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
I don't believe it should be the throttle block, I remove it and had it in there and witnessed the same behavior. The file does not contain the header sequence I am using as the access code in the correlate block. The file just says
"BEGIN
hello this is qpsk working!
END"

Here is a flowgraph working with raw bits, I changed the receive access code block to use the variable access_key instead of manually passing it in.

On Thu, May 8, 2025 at 9:19 PM Richard Bell <richard.bell4@gmail.com> wrote:
I took a look. There is an OOT block that I don't have used in the header creation part. I don't know if this is important, I suspect not given its name "throttle block". I also don't have the input file you were using. Does this file contain the header sequence you are using as the access code down in the correlate block? There is a variable called "access key" that doesn't seemed to be used by anything.

I can't get raw bits flow working in your flowgraph. Can you confirm on your end that the "correlate access code" block has the correct access key defined, and that this key is in fact injected into the header properly?

On Thu, May 8, 2025 at 12:31 PM Zachary Naymik <znaymik@mti-systems.com> wrote:
Flowgraph is attached.

On Thu, May 8, 2025 at 2:25 PM Richard Bell <richard.bell4@gmail.com> wrote:
Drop your qpsk flowgraph with plotting grc file here. When I have time later I'll run it and see what I can find.

On May 8, 2025, at 11:06 AM, Zachary Naymik <znaymik@mti-systems.com> wrote:

This bits only flowgraph works with the diff encoder and decoder with modulus of 4. Here is the flowgraph:
<image.png>

On Thu, May 8, 2025 at 1:47 PM Richard Bell <richard.bell4@gmail.com> wrote:
Also, in your bit level only flowgraph that you said works, can you insert the diff encoder and decoder blocks and show it still works?

On May 8, 2025, at 10:32 AM, Richard Bell <richard.bell4@gmail.com> wrote:

This is a bit level problem. This kind of problem is typically caused by assuming something about the input or output of one of these blocks that is not true. Carefully go through the blocks starting at the output of the constellation decoder and prove to yourself your input and output assumptions are correct. For example, I assumed the output of the constellation decoder would be bits, this was wrong.

On May 8, 2025, at 10:29 AM, Richard Bell <richard.bell4@gmail.com> wrote:

Can you visually see the sequence you expect coming out of the unpack block in either bpsk or qpsk?

On May 8, 2025, at 10:25 AM, Zachary Naymik <znaymik@mti-systems.com> wrote:

This also does not work for BPSK without the "Unpack K Bits" block either. Attached is the flowgraph and Time Sinks below.
<image.png>

On Thu, May 8, 2025 at 1:05 PM Zachary Naymik <znaymik@mti-systems.com> wrote:
That makes sense! However, I have added the "Unpack K Bits" block in 2 different configurations and neither work.
Configuration 1:
<image.png>
Configuration 2:
<image.png>

On Thu, May 8, 2025 at 12:52 PM Richard Bell <richard.bell4@gmail.com> wrote:
According to your plots, the constellation decoder doesn't output bits, it outputs packed bytes. In the case of QPSK that would mean 2 bits per output byte. We need to unpack those bytes into bits before entering the correlate block, which expects 1 bit per byte. This can be done using the "Unpack K Bits" block with "K = 2" for QPSK. For BPSK you wouldn't need to unpack anything, it should work by default because BPSK only has 1 bit per byte coming out. Confirm this.

Add the "Unpack K Bits" block after the differential decoder and feed this into the correlate block.

On Thu, May 8, 2025 at 9:16 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
I do see the valid bits out of the Differential Decoder. However, after removing the Map block, I still do not see anything on the other side of the Correlate Access Code block.

I do see the perfect dots in the 4 corners of the square like I have seen before in QPSK constellations. I understand that with noise the dots become more spread out into clouds instead of being perfect as they are in the simulation. Thank you for this information!

I have a USRP flowgraph in progress that I have halted progress on so far, but I do have those blocks added in there where you have specified in previous messages.

Here are the time sinks and the flowgraph in the state I have right now. I'm not sure what else I need to modify to make things work, however if I increase the threshold to 15 I can see things on the other side of the Correlate Access Code block if that helps you out at all.
<image.png>

Zach

On Thu, May 8, 2025 at 12:02 PM Richard Bell <richard.bell4@gmail.com> wrote:
The constellation decoder should be producing valid bits of 1's and 0's. Therefore, the map block after the differential decoder needs to be removed. This should be the last change you need to get correlations. Plot the time domain output after the differential decoder, you should see nice bits to prove it to yourself.

Regarding the good looking constellations, you should see nearly perfect dots at the four corners of a square (assuming QPSK). This is why I said it maximizes BER, these near perfect dots are directly correlated to BER. The tighter these dots, the better your BER. When you add a noise source to this simulation, like the AWGN channel I recommended, you will see these dots become clouds and grow as the noise power grows. I recommend you set this up for yourself next.

When you get to using radios, in the receiver you will want to add back the AGC before the RRC filter and the linear equalizer after the costas loop block. This should give you a good working over-the-air transceiver.

Rich

On Thu, May 8, 2025 at 7:59 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
I have changed the output SPS in the Symbol Sync to 1 and the constellations look great now. However, I still do not see anything after the Correlate Access Code block. You can see the flowgraph below with the changes.
<image.png>

On Thu, May 8, 2025 at 10:53 AM Richard Bell <richard.bell4@gmail.com> wrote:
You have the output samples per symbol in the symbol sync block set to 2. Make that 1 and try again.

On May 8, 2025, at 5:08 AM, Zachary Naymik <znaymik@mti-systems.com> wrote:

Richard,
I have constructed this flowgraph based on your changes, and I still do not see anything come through the other side of the Correlate Access Code block. I also tried with just the equivalent Constellation Encoder -> RRC Filter on the TX side, but still no luck. The flowgraph and constellations are attached below. If you need any more information from me after running this flowgraph, please let me know!
<image.png>

<image.png>

On Wed, May 7, 2025 at 2:01 PM Richard Bell <richard.bell4@gmail.com> wrote:
Getting closer, but not quite. You still have a rational resampler doing 16 to 1 decimation that shouldn't be there. The image I've attached is the structure I am trying to describe. Top row is transmitter, bottom row is receiver. The combination of the constellation encoder and RRC in the top row should be equivalent to your single constellation modulator object. The constellation modulator has the RRC built into it.

I also noticed that there is a poor choice for the default "number of taps" field in the RRC block (not your fault). It uses "11*sample_rate", which is not good. The FFT RRC filter length only depends on the sps and the total length you want it to be, in samples, to get the performance you want. This length is typically chosen to be around 11 symbols (that's where the 11 comes from) times the number of samples per symbol. This gives about 44 samples in length, independent of the sample rate. Notice my FFT RRC filter length is 44 and yours is 300k. I'm surprised the flowgraph even runs with a filter this long. Just change the "Num taps" field in the FFT RRC block to "11*sps", assuming you defined the sps variable like I have.

The costas loop order should be 2 for BPSK, and 4 for QPSK.

I did not run my flowgraph, I only put it together to show you what I've been describing in words. Hopefully I didn't overlook something. You will let me know.

<image.png>

On Wed, May 7, 2025 at 10:10 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
I reverted the Fractional Resampler's rate back to the default value (~60m) and added the filter, and the constellations look better than in my last email. They are pictured below, the Filter is the same as listed in my previous email. I still see no output on the other side of the "Coorelate Access Code" block though.
<image.png>

Thanks again,
Zach

On Wed, May 7, 2025 at 12:56 PM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
Thanks again for the feedback, I was trying to move onto USRPs - but will revert until the filter is implemented as you have advised. There was no data lost and the file transmission was working fine, here is what I have found while trying to implement the filter. Just taking a look at the constellations, and data flow.

Without the RRC Filter, I see these constellations from the Symbol Sync and Costas Loop:
<image.png>

With the addition of the RRC Filter, I see these constellations from the Symbol Sync and Costas Loop:
<image.png>

Before the filter as I stated above, the file is fully transmitted and repeated, however after adding the filter, I can see data going into the "Correlate Access Code" block, but nothing makes it out the other side.
Here is the filter that I added and where I added it in the flowgraph, I'm not sure what adjustments need to be made although I have tried some things - I have found no luck.

<image.png>

Thanks,
Zach

On Wed, May 7, 2025 at 12:39 PM Richard Bell <richard.bell4@gmail.com> wrote:
Hi Zachary,

I have to admit, I don't see how the flowgraph you say "works", could work. Maybe I'm not seeing a hidden parameter, but it looks to me like you are overall downsampling from the original symbol rate now, which means you should be seeing lost data.

Even if you are not losing data, and somehow the flowgraph does "work" in some way as it is shown, it will not work as well as it will if you follow my advice in the previous email. The RRC filters will improve the bit-error-rate (BER) compared to this one. I do recommend you try to implement the one I described, you will be happier. This relates to "opening the eye" of the constellation diagram, if you want to look that up.

Richard

On Wed, May 7, 2025 at 5:33 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
I have been able to achieve a purely simulated working text file transmission using QPSK modulation. I will attach the flowgraph and the image below. The change that allowed it to work was increasing the resampling ratio in the Fractional Resampler block - although I still do not have the RRC Filter. I got this working shortly before leaving the office yesterday and just looked at your new feedback this morning hence the RRC Filter being left out. Should I rework this flowgraph to use an RRC Filter as I'm assuming that is the "right" way to do this? I am now planning on using the other feedback that you have provided to adapt this simulated flowgraph to use USRPs and will update here with progress.

Simulated working QPSK Flowgraph:
<image.png>

Thanks,
Zach

On Tue, May 6, 2025 at 5:34 PM Richard Bell <richard.bell4@gmail.com> wrote:
Hi Zachary,

No problem, hopefully others will also get some useful information out of this thread as well. Thanks for letting me know. I'll try to explain with a little more detail.

1) In a QAM transceiver that is built to minimize bit-error-rate and optimize the synchronization performance, you will find two root-raised-cosine (RRC) filters, one in the transmitter, and one in the receiver.

2) The RRC in the transmitter is used to set the sample-per-symbol (sps) rate in the transmitter. The RRC in the receiver is used to set the sps in the receiver. Technically, these two sps do not need to be equal, but practically they often are setup that way. Let's get your transceiver working with the assumption that sps will be the same on both ends.

3) The way you set the samples per using the RRC filter, is by choosing the ratio of the sampling rate and the symbol rate to be equal to your sps rate. In the flowgraph that you included that contains the RRC, you have a sample rate of 48k and a symbol rate of 1. This means your sps is 48000 samples per symbol. This is the source of your current problem. In addition, you placed it right after the constellation modulator, as though it would exist in the transmitter at this location. In reality, this RRC would exist right before the symbol sync block in the receiver, and that's where I recommend you place it. The RRC for the transmitter is already included within the constellation modulator block for you by default, and is set to produce 4 samples per symbol.

4) If the only change you made to the flowgraph with the RRC in it is to set the sample rate of the RRC block from 48k to 4, I suspect it would start working. This is because it just so happens that the RRC is technically placed right before the symbol sync as it is, even though it doesn't look that way. The downstream blocks from the RRC just so happen to be identity operations in their current state.

5) I recommend creating a variable called "sps" and using this variable in all the blocks that require an explicit "samples per symbol", or use the ratio approach of wanting a "sample rate" and a "symbol rate". When a block wants both "sample rate" and "symbol rate", the first thing they usually do internally is create "sps = sample_rate / symbol_rate". When you set sample_rate = sps and symbol_rate = 1, you are doing so knowing this ratio is all it actually cares about. This is the case with the RRC block.

Hopefully that's all clear and your flowgraph starts to work. Let us know.

Richard

On Tue, May 6, 2025 at 5:21 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
Again - thank you for your guidance. I will admit I have no experience with signal processing so I appreciate you being patient with me. I have stripped the working BPSK flowgraph to work with the minimal amount of blocks I believe. However, when I add the RRC filter, the flowgraph will no longer work. I understand there might be some tuning I need to add to the RRC filter but I do not understand how to calculate what values I need to use or anything of that sort. I was also unsure of whether to use the FFT RRC Filter, or just the RRC filter. The flowgraphs are attached below. Any more feedback would be greatly appreciated.

Thanks again,
Zach

Working Stripped BPSK:
<image.png>

Non-functional Stripped BPSK w/ RRC Filter:
<image.png>

On Thu, May 1, 2025 at 3:41 PM Richard Bell <richard.bell4@gmail.com> wrote:
Zachary,

I mentioned in my previous reply, you can remove the AGC, FLL, and Equalizer blocks from the original flowgraphs, those would be examples of optional blocks. The equalizer is only needed if a realistic channel exists, the AGC if realistic power fluctuation exists, and the FLL if large sources of frequency offset exist, like doppler from satellites moving around. For now all those effects should be left out. Don't use real radios until this works in pure simulation with an AWGN channel only. Then you can add these optional components and begin testing with radios.

This is all advice from my past experiences.

Rich

On Thu, May 1, 2025 at 12:34 PM Richard Bell <richard.bell4@gmail.com> wrote:
Zachary,

I would not call this the "smallest step" possible because this flowgraph just won't work. You are trying to do synchronization on a signal that was never modulated by the transmitter (why do you want that FFT filter in there, the RRC filter that is missing is all the filtering you need in the transmit chain). The costas loop requires at least 2 samples per symbol, but you are feeding in raw symbols (1 sample per symbol). Once you have more than 1 sample per symbol, you will require timing recovery, so that block will need to go back in also.

It's good that you proved the raw bits flowgraph works, that is a good starting point. Now go back to the BPSK that was working and the QPSK that wasn't working, and implement the changes I mention in steps 3 and 4.

Let us know how it turns out.

Rich

On Thu, May 1, 2025 at 5:45 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
I have heeded your advice and I have the stripped flowgraph working as described in step 1. However, I am trying to adapt the flowgraph to work as in step 2 but the only synchronization block I am able to add is the Costas Loop, if I add any other synchronization block the data does not make it through the correlation of the access code. Here is what I have for step 2, again I thank you for your advice and help - if you can give any more guidance that would be great.

<image.png>

Thanks,
Zach

On Tue, Apr 29, 2025 at 1:27 PM Richard Bell <richard.bell4@gmail.com> wrote:
Hi Zachary,

I do see some problems with your flowgraph. I can recommend a debug strategy that I would use to figure out the root cause.

1) In the flowgraph that doesn't work, strip it down as much as possible such that you still have a working flowgraph. For example, remove all the synchronization blocks so that you only have the "bits -> packetize -> encoder -> decoder -> depacketize -> bits" flow working.

2) From the working flowgraph that is just bits in the previous step, start adding back synchronization blocks, using the smallest steps possible, and only those blocks that are absolutely required. For example, I would leave out the AGC and FLL in this step.

3) The constellation modulator block applies a root raised cosine (RRC) pulse shape to the transmitted signal. In your receiver, you are missing the symmetric RRC filter in the demodulation process. There should be one before the timing recovery block in both BPSK and QPSK. The BPSK may be able to work without it, albeit with a much worse bit error rate, while the QPSK fails completely.

4) The linear equalizer in your QPSK block should come after the costas loop block. Equalizers generally want phase and timing synchronized input.

5) Make sure all the upsampling/downsampling rates are correct in the QPSK graph. You switch to using 8 samples per symbol, instead of 4, so it's possible other rate changes need to be adjusted to reflect this. I didn't go through and do the math myself. I personally wouldn't recommend you increase the samples per symbol from 4 to 8. I would use 2 or 4 in both graphs.

Give these suggestions a try and let us know if anything improves.

Rich

On Tue, Apr 29, 2025 at 5:12 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Richard,
Thank you for the guidance. I believe I have made all the necessary changes to the modulation and synchronization technique.
BSPK Flowgraph (working):
<image.png>

QPSK Flowgraph (not working):
<image.png>

If you have anything for me to try or experiment with please let me know.
Thanks,
Zach

On Thu, Apr 24, 2025 at 1:27 PM Richard Bell <richard.bell4@gmail.com> wrote:
Hi Zachary,

You will have a better chance of getting responses if you post screenshots of your flowgraph instead of attaching grc files themselves. People can't open grc files on their phones or on the go.

I have not opened your grc files, have you made the proper change to the synchronization technique you are using to account for the change in modulation type from 2 symbols to 4 symbols? That's the first place my mind went that would cause problems.

Rich

On Wed, Apr 16, 2025 at 5:53 AM Zachary Naymik <znaymik@mti-systems.com> wrote:
Hello all,
I am reaching out again as I am trying to modify a working file transmission using BPSK to work using QPSK. I have made all the modifications I believe to be necessary to get the transmission to work with QPSK, however I am unable to see any results. I have debugged this for many hours and am reaching out to see if anyone has any insight. Please let me know if you have any questions, the flowgraphs are attached.

Thanks,
Zach

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

--
Zach Naymik | Software Engineer
e: znaymik@MTi-Systems.com p: 330-931-9945
https://mti-systems.com

Zach Naymik | Software Engineer

e: znaymik@MTi-Systems.com p: 330-931-9945

https://mti-systems.com