Re: Inconsistent I/Q Channel Output with single Pluto for BPSK tx and rx

On Sat, Jun 14, 2025 at 3:26 PM Maciej Zemło <mzemlo.pl@gmail.com> wrote:

Hi,

I'm testing a basic BPSK tx-rx chain using GNU Radio v3.10.12.0 with a single Pluto device. The system performs BPSK modulation on a constant bit stream (0x0A) and transmits it via the PlutoSDR's TX (cycle on), while the RX path is connected in a loopback configuration.

https://github.com/yabool2001/gnuradio/blob/main/yabool2001/BPSK_02/BPSK_test_02_1.1.grc

Each time I run the script, the received I and Q components appear in a different arrangement. Sometimes the signal appears predominantly on the I channel, other times on Q, or even rotated. The transmitted waveform remains constant and is visualized properly in the TX time sink, while the RX signal varies significantly in phase alignment between subsequent executions. A set of plots showing these differences is available at:

https://github.com/yabool2001/gnuradio/blob/main/yabool2001/BPSK_02/results.jpg

This phase ambiguity is inherent in the system and the modulation. Each local oscillator being used are separately tuned which introduces the phase shift.

 

I'd appreciate even a brief signal on whether this behavior is expected and how it is typically addressed. Would using two separate Pluto units (one for TX and one for RX) eliminate this ambiguity?

If you want to keep regular BPSK, then typically you'll send some synchronization pattern to figure out "which way is up". The undoing of this is a simple phase rotation (complex multiplication) with the complex conjugate of the result of the correlation between what was sent and what was received.

If you want to get rid of all ambiguities in general, and you're willing to take a 3 dB performance hit, switch to differential BPSK. This looks at just the difference between the previous symbol and the current symbol to get the actual message data. Phase ambiguities are eliminated using this method.

Good luck.

Brian

Inconsistent I/Q Channel Output with single Pluto for BPSK tx and rx

Hi,

I'm testing a basic BPSK tx-rx chain using GNU Radio v3.10.12.0 with a single Pluto device. The system performs BPSK modulation on a constant bit stream (0x0A) and transmits it via the PlutoSDR's TX (cycle on), while the RX path is connected in a loopback configuration.

https://github.com/yabool2001/gnuradio/blob/main/yabool2001/BPSK_02/BPSK_test_02_1.1.grc

Each time I run the script, the received I and Q components appear in a different arrangement. Sometimes the signal appears predominantly on the I channel, other times on Q, or even rotated. The transmitted waveform remains constant and is visualized properly in the TX time sink, while the RX signal varies significantly in phase alignment between subsequent executions. A set of plots showing these differences is available at:

https://github.com/yabool2001/gnuradio/blob/main/yabool2001/BPSK_02/results.jpg

I'd appreciate even a brief signal on whether this behavior is expected and how it is typically addressed. Would using two separate Pluto units (one for TX and one for RX) eliminate this ambiguity?

Best regards,
Yabool2001

GRCon25 Abstract Submission Deadline - Due Today!!

Reminder - today is the final abstract submission deadline for GRCon25.  

Please let us know ASAP if you have any questions or run into issues submitting by this deadline (midnight US Pacific Time tonight!)

Josh

On Tue, Jun 3, 2025 at 2:10 PM Josh Morman (GNU Radio) <jmorman@gnuradio.org> wrote:

Greetings! 

We have received a good number of quality submissions for the GRCon25 Call for Participation.  We are however going to extend the final deadline to June 13.  So if you have a project or topic you would like to share at the conference, please submit as this will be the final deadline.  Note that all is needed is a short abstract - so go ahead and let us know what you want to present!

------------------------------------

This year's conference will be held September 8-12, 2025, in the Seattle area, and we would love to see your work featured once again.

We're inviting presentations, papers, workshops, demos, or any creative ideas you'd like to share. If you've been working on something exciting in the world of SDR, wireless systems, AI/ML, 5G/6G, education, radio astronomy, amateur radio, hardware integration, or any other relevant field -- now is the time to submit!

🔹 Submission deadline: May 30, 2025  June 13, 2025
🔹 Submit here: https://gnuradio.org/grcon25

New this year:
Accepted presenters are eligible for a $200 registration discount upon request. We hope this helps make the event more accessible. If you're attending from a well-funded organization and don't need the discount, we kindly ask that you leave it available for others who do.

If you're interested but can't meet the deadline, please contact us at grcon@gnuradio.org as soon as possible - we will do our best to accommodate.

We look forward to seeing many familiar faces and fresh ideas this September in Everett, WA!

Sincerely,

Josh Morman

on behalf of the GRCon25 Organizers

Re: Integrating GRC-Generated Python Code into Python Virtual Environment

Hi Hamza,

it's great that you ask the mailing list! Because I've already replied to you in chat, I
think it's a good idea to echo what I wrote there here, so that people will find an answer
when they look for answers in the future:

If you want the system-installed GNU Radio to be available in your virtual environment,

python3 -m venv --system-site-packages

sets up your virtual environment in a way that allows access to the system-wide python
modules.

This is necessary, because numpy, pyqt, … as used by GNU Radio during built must be
ABI-compatible. You must not install a different version of these libraries in the virtual
environment!

Best regards,
Marcus

On 6/8/25 8:01 AM, Hamza Mohammed wrote:
> Hello all,
>
> I'm currently working on a standalone FM receiver Python application and would like to
> integrate a GNU Radio Companion (GRC) flow graph—specifically, FM receiver that I've
> already built and verified to work correctly.
>
> However, I'm unsure about the best approach to use the Python code generated by GRC within
> a Python virtual environment. My goal is to cleanly integrate the flow graph functionality
> into my application's codebase, ideally without relying on a system-wide GNU Radio
> installation.
>
> So far, I've considered a couple of possible options:
>
> 1.
>
> *Creating symbolic links* from my virtual environment to the system-installed GNU
> Radio libraries and Python modules.
>
> 2.
>
> *Using Conda* to install GNU Radio directly within a self-contained environment,
> avoiding the need for system-wide dependencies.
>
> Before I go too far down either path, I wanted to ask you guys.
>

Integrating GRC-Generated Python Code into Python Virtual Environment

Hello all,

I'm currently working on a standalone FM receiver Python application and would like to integrate a GNU Radio Companion (GRC) flow graph—specifically, FM receiver that I've already built and verified to work correctly.

However, I'm unsure about the best approach to use the Python code generated by GRC within a Python virtual environment. My goal is to cleanly integrate the flow graph functionality into my application's codebase, ideally without relying on a system-wide GNU Radio installation.

So far, I've considered a couple of possible options:

1. Creating symbolic links from my virtual environment to the system-installed GNU Radio libraries and Python modules.

2. Using Conda to install GNU Radio directly within a self-contained environment, avoiding the need for system-wide dependencies.

Before I go too far down either path, I wanted to ask you guys. 

Re: Feedback Wanted: UI of FM receiver GsoC project

If it is for the "Play" button, then it should be better named as "mute" or maybe "Squelch" and being processed with reverse logic:
    If pressed it should either reduce the audio volume by 20 dB (audio level), or maybe even totally mute the sound.

Or, maybe you want to implement something like "Squelch" - depending on RF signal level for example - then you could use it to switch on or off the muting of hissing sounds, while not receiving enough RF level for decoding the FM signal without background noise.
Maybe it could be even used to swith on/ off in different levels, so it
   * only would produce audio output on really strong RF levels with good signal quality, where the audio signal would be almost completely without any hiss.
   * Next level would be switching on for stations that can provide bearable stereo sound with some light hissing but producing mono sound almost without hissing.
   * And the next level then would be "always on" for audio output, so even the FM hissing sound will be presented.

But what I'm totally missing at that GUI is something to indicate and switch on/ off Stereo decoding! Weak stations or bad receiption situations may still work well, if you only have Mono, but then lead to ugly hissing, when trying to process the signal in stereo.
Also for some persons the TS (traffic service)/ TA (traffic announcement) Flags are important, that are indicated by some additional pilot tone while in the audio (baseband) spectrum. Thinking for example of some car radio being equiped with your receiver.
One could also think of some colour change for the display, either for signal quality, or (as it was used in vintage car stereo systems from "Blaupunkt") for indication of the traffic-service/ traffic-announcement - one colour for standard service, another one for traffic service/ announcement....

There were lots of good and innovative things already, when you look at old radio receivers (who would not love to have the "magic eye tube" display to show signal strength...?) ;-)



Best regards,
Wolfgang






 Am 05.06.25 um 15:54 schrieb Marcus Müller:

Hi Hamza,

love it! Would leave out the song cover display, to be honest – showing the textual RDS info is enough for almost all users, and you'd need not care about fetching covers. And I don't know where you'd be getting station logos from; to the best of my logo, RDS doesn't transmit logos.
As such, I think your channel list might be relying too heavily on the station icons being visually distinguishing elements! And these icons don't exist in the radio transmission!

I'd rather have a larger (RDS terminology) *Programme Service Name* being displayed (it can only be 8 characters long!) or *Long Programme Service Name* (LPS, when available, <=32 UTF-8 characters), with the frequency found displayed below in a smaller font, and maybe the *Programme Type* (PTY) and *Programme Type Name* (PTYN) when available. I think keeping space for a (later) signal strength indicator would be cool, too.

Something like:

 ___ ___  ___ ____ _   ___ _    _   _               _   ___ _        _   _
| _ ) _ )/ __|__  (_) | __(_)__| |_(_)___ _ _  __ _| | / __| |_ __ _| |_(_)___ _ _
| _ \ _ \ (__  / / _  | _|| / _|  _| / _ \ ' \/ _` | | \__ \  _/ _` |  _| / _ \ ' \
|___/___/\___|/_/ (_) |_| |_\__|\__|_\___/_||_\__,_|_| |___/\__\__,_|\__|_\___/_||_|

 🯱 🯰 🯰 .🯰 🯰 MHz    📶███████▒░░░    Education / Bringing you the coolest fiction!


(of course, not as ASCII-art, but I didn't have my graphics editor handy.)


I'm not sure what a "play" (▶) / next (⏵|)/ previous (|⏴) button does in a radio receiver? If you mean "jump to next/previous found station", then please use vertically pointing arrows instead of left and right – your station list is vertical, too!
(I'm still not sure what the "play" button does in a radio receiver – it's not a cassette player!)

I don't specifically like the spotify UI (my media player software is kind of the opposite of spotify in so many ways), so I'm not very qualified to critique the overall design. But: you have a lot of space around your channel list and waterfall display, so I'd suggest you make the buttons beneath as large and easy to hit for even someone shortsighted as possible, and make the volume slider have a large, easy to see "handle": I really think that the common loudness sliders where the user needs to know that they can drag the end, without the end actually having a visible "knob" is a design mistake, as I've seen *multiple* people fail to try doing that, because common UX expectation is that things your can interact with are somewhat "button shaped".

The "heart" icon seems to be "blindly stolen" from spotify and cannot serve a purpose on a radio receiver, so I'd strongly recommend removing it.

Best regards,
Marcus
On 6/4/25 10:20 PM, Hamza Mohammed wrote:

Hi everyone! As part of my GSoC project, I've been working on an FM radio app, and I just finished the first layout draft—would love your thoughts!

Main features:

  *

    *Debug view*: FM receiver controls like sampling rate, filter size, squelch, gain
    (still working on this part)

  *

    *Home page*: Auto SDR detection, frequency scanning, channel listing, multi-stream
    recording with RDS (station info, song titles, etc.)

  *

    *On-demand flowgraph control* for better performance

The UI is kinda Spotify-inspired. I've attached sketches and Figma mockups—let me know if it's missing something, looks off, or just feels boring. First time designing an app, so all feedback is welcome!

Re: Feedback Wanted: UI of FM receiver GsoC project

Hi Hamza,

love it! Would leave out the song cover display, to be honest – showing the textual RDS
info is enough for almost all users, and you'd need not care about fetching covers. And I
don't know where you'd be getting station logos from; to the best of my logo, RDS doesn't
transmit logos.
As such, I think your channel list might be relying too heavily on the station icons being
visually distinguishing elements! And these icons don't exist in the radio transmission!

I'd rather have a larger (RDS terminology) *Programme Service Name* being displayed (it
can only be 8 characters long!) or *Long Programme Service Name* (LPS, when available,
<=32 UTF-8 characters), with the frequency found displayed below in a smaller font, and
maybe the *Programme Type* (PTY) and *Programme Type Name* (PTYN) when available. I think
keeping space for a (later) signal strength indicator would be cool, too.

Something like:

___ ___ ___ ____ _ ___ _ _ _ _ ___ _ _ _
| _ ) _ )/ __|__ (_) | __(_)__| |_(_)___ _ _ __ _| | / __| |_ __ _| |_(_)___ _ _
| _ \ _ \ (__ / / _ | _|| / _| _| / _ \ ' \/ _` | | \__ \ _/ _` | _| / _ \ ' \
|___/___/\___|/_/ (_) |_| |_\__|\__|_\___/_||_\__,_|_| |___/\__\__,_|\__|_\___/_||_|

🯱 🯰 🯰 .🯰 🯰 MHz 📶███████▒░░░ Education / Bringing you the coolest fiction!


(of course, not as ASCII-art, but I didn't have my graphics editor handy.)


I'm not sure what a "play" (▶) / next (⏵|)/ previous (|⏴) button does in a radio receiver?
If you mean "jump to next/previous found station", then please use vertically pointing
arrows instead of left and right – your station list is vertical, too!
(I'm still not sure what the "play" button does in a radio receiver – it's not a cassette
player!)

I don't specifically like the spotify UI (my media player software is kind of the opposite
of spotify in so many ways), so I'm not very qualified to critique the overall design.
But: you have a lot of space around your channel list and waterfall display, so I'd
suggest you make the buttons beneath as large and easy to hit for even someone
shortsighted as possible, and make the volume slider have a large, easy to see "handle": I
really think that the common loudness sliders where the user needs to know that they can
drag the end, without the end actually having a visible "knob" is a design mistake, as
I've seen *multiple* people fail to try doing that, because common UX expectation is that
things your can interact with are somewhat "button shaped".

The "heart" icon seems to be "blindly stolen" from spotify and cannot serve a purpose on a
radio receiver, so I'd strongly recommend removing it.

Best regards,
Marcus
On 6/4/25 10:20 PM, Hamza Mohammed wrote:
> Hi everyone! As part of my GSoC project, I've been working on an FM radio app, and I just
> finished the first layout draft—would love your thoughts!
>
> Main features:
>
> *
>
> *Debug view*: FM receiver controls like sampling rate, filter size, squelch, gain
> (still working on this part)
>
> *
>
> *Home page*: Auto SDR detection, frequency scanning, channel listing, multi-stream
> recording with RDS (station info, song titles, etc.)
>
> *
>
> *On-demand flowgraph control* for better performance
>
> The UI is kinda Spotify-inspired. I've attached sketches and Figma mockups—let me know if
> it's missing something, looks off, or just feels boring. First time designing an app, so
> all feedback is welcome!
>