Question about .qss files?

Hello

At Marcus's suggestion I was successful in improving my gnuradio displays by using the
"QT Style Sheets (.qss) files.

However I can not (for the life of me) find the setting that brightens and enlarges
the QT menu's select buttons. I can change the color of the selected item (see attached).

This a minor point, but I'd like the selected item to have a brighter and bigger
mark. In the capture, "Average" is selected, but the select button is small and faint.
Does anybody know how to change the color of the selected item and make the button bigger?
It seems linked to all marks can be colored and scaled, but I can't guess the select field name.

thanks

Glen

Style sheet attached, also

Re: Help with setting manually occupied carriers in a OFDM allocator

Hi Miguel.

U's mean you are not sending samples to the USRP Sink device fast enough. It is having to read and send from the transmit buffer before you've set all the memory. O's mean the USRP source device buffer is not being read from fast enough, it is overflowing before you read from it.

The sample rate of your USRP devices is the ultimate stressor for this behavior. The higher the sample rate, the more likely you are to encounter O's and/or U's. This rate, coupled with the amount of processing you have to do in the transmit and receive paths, ultimately determines whether you will get O's or U's.

What sample rate are you using, and are you required to use this rate? Is there a sample rate you can lower the tx/rx to that makes the U's and O's go away? 

If there is no sample rate that makes the O's and U's go away, then the amount of processing you're doing is the problem. You need to do less, get more efficient at what you're doing, or a combination of the two. If you don't need a realtime system, you can preprocess the entire transmitter and dump what would feed the transmitter into a file. Then when you use a USRP, all you do is read from a file directly into the transmitter. The same can be done on the receiver. Dump the USRP directly into a file. Then read from that file and process it through the receive chain.

Hope this helps.

Rich

On Tue, Apr 29, 2025 at 6:20 AM Miguel Calvo <micalost14@gmail.com> wrote:

Hi everyone,

I'm working on a cognitive radio demonstrator as part of my bachelor thesis and I'm currently facing issues with overflows and underflows in my GNU Radio flowgraph when using a USRP device. 

I've attached screenshots of my flowgraph for simulations:

I think the issue might be related to my OOT blocks. The problem is that I need to dynamically set the occupied carriers, but with the existing GNU Radio blocks, I couldn't find a way to do it — so I created a custom block for that purpose.

However, due to latency between the two inputs of the allocator block, it ends up crashing. I modified my code to use buffers, but the performance is quite slow.

Does anyone have suggestions on how to address this issue, or any ideas on how to dynamically set the number of subcarriers in the allocator with an existing block?:

Thanks in advance.

Here is the code of the allocator block:

import numpy as np
from collections import deque
from gnuradio import gr

class Allocator(gr.sync_block):
    """
    Allocator block optimized for performance
    """
    def __init__(self, mask_len=128):
        gr.sync_block.__init__(self,
            name="Allocator",
            in_sig=[np.complex64, (np.float32, mask_len)],  
            out_sig=[(np.complex64, mask_len)]  
        )

        self.mask_len = mask_len  
        self.data_buffer = np.zeros(0, dtype=np.complex64)  
        self.mask_buffer = deque()  

    def work(self, input_items, output_items):
        in_data = input_items[0]
        in_mask = input_items[1]
        out = output_items[0]

        n_symbols = min(len(in_mask), len(out))

        
        self.data_buffer = np.append(self.data_buffer, in_data)

       
        self.mask_buffer.extend(in_mask)

        symbols_written = 0
        data_idx = 0

        
        for i in range(n_symbols):
            if len(self.mask_buffer) == 0:
                break  

            mask = self.mask_buffer.popleft()  

            if len(mask) != self.mask_len:
                raise ValueError(f"error mask len")
           
           
            occupied_carriers = np.where(mask < 0.5)[0]
            num_occupied = len(occupied_carriers)

            
            if data_idx + num_occupied > len(self.data_buffer):
                break  

            
            ofdm_symbol = np.zeros(self.mask_len, dtype=np.complex64)
            ofdm_symbol[occupied_carriers] = self.data_buffer[data_idx:data_idx + num_occupied]

            
            data_idx += num_occupied

            
            out[i][:] = ofdm_symbol
            symbols_written += 1

        
        self.data_buffer = self.data_buffer[data_idx:]

        return symbols_written

Re: Modifying BPSK to QPSK

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):

QPSK Flowgraph (not working):

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

Help with setting manually occupied carriers in a OFDM allocator

Hi everyone,

I'm working on a cognitive radio demonstrator as part of my bachelor thesis and I'm currently facing issues with overflows and underflows in my GNU Radio flowgraph when using a USRP device. 

I've attached screenshots of my flowgraph for simulations:

I think the issue might be related to my OOT blocks. The problem is that I need to dynamically set the occupied carriers, but with the existing GNU Radio blocks, I couldn't find a way to do it — so I created a custom block for that purpose.

However, due to latency between the two inputs of the allocator block, it ends up crashing. I modified my code to use buffers, but the performance is quite slow.

Does anyone have suggestions on how to address this issue, or any ideas on how to dynamically set the number of subcarriers in the allocator with an existing block?:

Thanks in advance.

Here is the code of the allocator block:

import numpy as np
from collections import deque
from gnuradio import gr

class Allocator(gr.sync_block):
    """
    Allocator block optimized for performance
    """
    def __init__(self, mask_len=128):
        gr.sync_block.__init__(self,
            name="Allocator",
            in_sig=[np.complex64, (np.float32, mask_len)],  
            out_sig=[(np.complex64, mask_len)]  
        )

        self.mask_len = mask_len  
        self.data_buffer = np.zeros(0, dtype=np.complex64)  
        self.mask_buffer = deque()  

    def work(self, input_items, output_items):
        in_data = input_items[0]
        in_mask = input_items[1]
        out = output_items[0]

        n_symbols = min(len(in_mask), len(out))

        
        self.data_buffer = np.append(self.data_buffer, in_data)

       
        self.mask_buffer.extend(in_mask)

        symbols_written = 0
        data_idx = 0

        
        for i in range(n_symbols):
            if len(self.mask_buffer) == 0:
                break  

            mask = self.mask_buffer.popleft()  

            if len(mask) != self.mask_len:
                raise ValueError(f"error mask len")
           
           
            occupied_carriers = np.where(mask < 0.5)[0]
            num_occupied = len(occupied_carriers)

            
            if data_idx + num_occupied > len(self.data_buffer):
                break  

            
            ofdm_symbol = np.zeros(self.mask_len, dtype=np.complex64)
            ofdm_symbol[occupied_carriers] = self.data_buffer[data_idx:data_idx + num_occupied]

            
            data_idx += num_occupied

            
            out[i][:] = ofdm_symbol
            symbols_written += 1

        
        self.data_buffer = self.data_buffer[data_idx:]

        return symbols_written

Re: Modifying BPSK to QPSK

Richard,

Thank you for the guidance. I believe I have made all the necessary changes to the modulation and synchronization technique.

BSPK Flowgraph (working):

QPSK Flowgraph (not working):

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

Re: Compatibility Issues with gr-ieee802-11 Library

Hi Pedro,

The preferred approach depends on quite a few things. 

Do you want to use the OOT as is? If you want to install and transmit or receive, the apt approach would be best. I guess the package is named differently though. e.g. gnuradio-gr... This would be easy to find online.

Another approach would be to use condo/radioconda. Your desired OOT might already be packaged there as well.

If you want to work with the source and update it, make sure you checked out the correct branch. I suspect maint-3.10 would be the one you're looking for. Also, that'd get rid of the swig related error.

There's a wiki page where I go back quite frequently gnuradio conda install. 

Have fun 

Pedro Tapia <pedrotapia@cpejr.com.br> schrieb am Fr., 25. Apr. 2025, 19:16:

Hi everyone,

I've been struggling to get the gr-ieee802-11 library working on Ubuntu 24.04 with GNU Radio 3.10.9.2 and would appreciate any advice. Here's what I've tried and the errors I'm hitting:

Problem Summary

The library fails to:

1. Install via apt (package missing)

2. Compile from source (CMake errors)

3. Import in Python (ModuleNotFoundError)

Steps Taken

1. Installation Attempts:

bash

# Tried official packages (not found)    sudo apt install gr-ieee802-11    # → E: Unable to locate package      # Tried pip (externally-managed error)    pip install git+https://github.com/bastibl/gr-ieee802-11.git    # → error: externally-managed-environment  

2. Manual Compilation:

bash

git clone https://github.com/bastibl/gr-ieee802-11.git    cd gr-ieee802-11 && mkdir build && cd build    cmake -DCMAKE_INSTALL_PREFIX=/usr ..  

Errors:

plaintext

CMake Error: include could not find requested file: GrSwig    CMake Error: Unknown CMake command "GR_SWIG_MAKE"  

3. Workarounds Tried:

• Used libgnuradio-ieee80211 from gnuradio-releases PPA (not updated for Noble)

• Tried older branches (maint-3.8, maint-3.9) – same issues

Questions

1. Has anyone successfully built this on Ubuntu 24.04?

2. Are there forks with updated CMake support?

3. Any alternatives for WiFi MAC-layer decoding in GNU Radio?

   I would like to ask for help, using GNURADIO, over here it's a picture of my work it's correct? How can I do better? I hope to detect the Wi-Fi name at least

Obter o Outlook para iOS

problems allocating a buffer with the given max output buffer constraint!

The subject line says it all. I received this error (which is detailed below) recently while executing a flowgraph of a project which has been running successfully.

 

Several of the blocks have their output buffers assigned to values other than their default. This was necessary to permit this particular application to operate properly.

 

I don't know why I suddenly have this issue. it seemed to arise after I had some complications occur due to a "sudo apt upgrade" that I performed.

 

I realize that this explanation is vague but I don't know where to begin to troubleshoot this issue. I can make the problem go away by removing the buffer setting from an analog source block but then the application ceases to work properly.

 

Please help point me to the right path here.

 

Exception in thread Receive:

Traceback (most recent call last):

  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner

    self.run()

  File "/usr/lib/python3.11/threading.py", line 975, in run

    self._target(*self._args, **self._kwargs)

  File "/usr/local/lib/python3.11/dist-packages/ft8_rxtx/ft8_rxtx.py", line 137, in rx

    FT8_Receive.main()

  File "/home/wa4ywm/Softrock/FT8_Receive.py", line 226, in main

    tb.start()

  File "/usr/lib/python3/dist-packages/gnuradio/gr/top_block.py", line 100, in start

    top_block_start_unlocked(self._impl, max_noutput_items)

RuntimeError: problems allocating a buffer with the given max output buffer constraint!

Virus-free.www.avg.com

Compatibility Issues with gr-ieee802-11 Library

Hi everyone,

I've been struggling to get the gr-ieee802-11 library working on Ubuntu 24.04 with GNU Radio 3.10.9.2 and would appreciate any advice. Here's what I've tried and the errors I'm hitting:

Problem Summary

The library fails to:

1. Install via apt (package missing)

2. Compile from source (CMake errors)

3. Import in Python (ModuleNotFoundError)

Steps Taken

1. Installation Attempts:

bash

# Tried official packages (not found)   sudo apt install gr-ieee802-11   # → E: Unable to locate package    # Tried pip (externally-managed error)   pip install git+https://github.com/bastibl/gr-ieee802-11.git   # → error: externally-managed-environment  

2. Manual Compilation:

bash

git clone https://github.com/bastibl/gr-ieee802-11.git   cd gr-ieee802-11 && mkdir build && cd build   cmake -DCMAKE_INSTALL_PREFIX=/usr ..  

Errors:

plaintext

CMake Error: include could not find requested file: GrSwig   CMake Error: Unknown CMake command "GR_SWIG_MAKE"  

3. Workarounds Tried:

• Used libgnuradio-ieee80211 from gnuradio-releases PPA (not updated for Noble)

• Tried older branches (maint-3.8, maint-3.9) – same issues

Questions

1. Has anyone successfully built this on Ubuntu 24.04?

2. Are there forks with updated CMake support?

3. Any alternatives for WiFi MAC-layer decoding in GNU Radio?

   I would like to ask for help, using GNURADIO, over here it's a picture of my work it's correct? How can I do better? I hope to detect the Wi-Fi name at least

Obter o Outlook para iOS

Re: Modifying BPSK to QPSK

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

Re: Dynamic variables in C++ OOT for Gnu Radio 3.10

Hello!

Glad to hear you got it to work :)

Best regards,
Marcus

On 4/24/25 4:26 PM, Huang Wei wrote:
> Hello Marcus,
>
> I have made it work, by checking some of your answers before. Here are the steps, in case
> someone else is interested:
>
> 1. define the set_param() function in lib/myblock_imp.h file:
>      Public:
>          ...
>          void set_param(float param) {_param = param;}
> 2. Add in the lib/myblock_imp.cc file:
>      _param = param;
> 3. In include/gnuradio/customModule/myblock.h add:
> Public:
>          ...
>          virtual void set_param(float param) = 0;
> 4. run "md5sum include/gnuradio/customModule/myblock.h" to get the tag value.
> 5. copy and paste the tag value in "BINDTOOL_HEADER_FILE_HASH(xxxx)" in the file python/
> customModule/bindings/myblock_python.cc
> 6. then do cmake../, make, sudo make install and sudo ldconfig. It should work now.
> 7. I also did "gr_modtool bind myblock", but I'm not sure if it helped or not.
>
> Best regards,
> Wei
>
> On Thu, 24 Apr 2025 at 11:42, Marcus Müller <mmueller@gnuradio.org
> <mailto:mmueller@gnuradio.org>> wrote:
>
> Hi Huang Wei,
>
> nice to have you here!
>
> Can you show us where you use `_param` in your C++ implementation?
> What you show us looks right, in general.
>
> Best regards,
> Marcus
>
> On 4/22/25 4:56 PM, Huang Wei wrote:
> > And I have added in the .yml file:
> > callbacks:
> > - set_param(${param})
> >
> > But still the value can't be changed.
> >
> > On Tue, 22 Apr 2025 at 15:16, Huang Wei <weizardry@gmail.com
> <mailto:weizardry@gmail.com> <mailto:weizardry@gmail.com <mailto:weizardry@gmail.com>>>
> > wrote:
> >
> >     Hello everyone,
> >
> >     In Gnu Radio 3.10, how to set a variable in a C++ OOT block that can be adjusted
> >     dynamically by a QT GUI range?
> >     I did in a .h file:
> >        Private:
> >          float _param;
> >        Public:
> >          void set_param(float param) {_param = param;}
> >     and in the impl.cc file:
> >        _param = param;
> >
> >     anywhere else I need to change? I just tried before in Gnu Radio 3.7, and now I am
> >     very lost with the new version.
> >
> >     Thank you very much.
> >
> >     Regards,
> >     Wei
> >
> >
>
>

Re: Dynamic variables in C++ OOT for Gnu Radio 3.10

Hello Marcus,

I have made it work, by checking some of your answers before. Here are the steps, in case someone else is interested:

1. define the set_param() function in lib/myblock_imp.h file: 

     Public:

         ...

         void set_param(float param) {_param = param;}

2. Add in the lib/myblock_imp.cc file:

     _param = param;

3. In include/gnuradio/customModule/myblock.h add:

      Public:

         ...

         virtual void set_param(float param) = 0;

4. run "md5sum include/gnuradio/customModule/myblock.h" to get the tag value.

5. copy and paste the tag value in "BINDTOOL_HEADER_FILE_HASH(xxxx)" in the file python/customModule/bindings/myblock_python.cc

6. then do cmake../, make, sudo make install and sudo ldconfig. It should work now.

7. I also did "gr_modtool bind myblock", but I'm not sure if it helped or not. 

Best regards,

Wei

On Thu, 24 Apr 2025 at 11:42, Marcus Müller <mmueller@gnuradio.org> wrote:

Hi Huang Wei,

nice to have you here!

Can you show us where you use `_param` in your C++ implementation?
What you show us looks right, in general.

Best regards,
Marcus

On 4/22/25 4:56 PM, Huang Wei wrote:
> And I have added in the .yml file:
> callbacks:
> - set_param(${param})
>
> But still the value can't be changed.
>
> On Tue, 22 Apr 2025 at 15:16, Huang Wei <weizardry@gmail.com <mailto:weizardry@gmail.com>>
> wrote:
>
>     Hello everyone,
>
>     In Gnu Radio 3.10, how to set a variable in a C++ OOT block that can be adjusted
>     dynamically by a QT GUI range?
>     I did in a .h file:
>        Private:
>          float _param;
>        Public:
>          void set_param(float param) {_param = param;}
>     and in the impl.cc file:
>        _param = param;
>
>     anywhere else I need to change? I just tried before in Gnu Radio 3.7, and now I am
>     very lost with the new version.
>
>     Thank you very much.
>
>     Regards,
>     Wei
>
>

Re: Dynamic variables in C++ OOT for Gnu Radio 3.10

Hi Huang Wei,

nice to have you here!

Can you show us where you use `_param` in your C++ implementation?
What you show us looks right, in general.

Best regards,
Marcus

On 4/22/25 4:56 PM, Huang Wei wrote:
> And I have added in the .yml file:
> callbacks:
> - set_param(${param})
>
> But still the value can't be changed.
>
> On Tue, 22 Apr 2025 at 15:16, Huang Wei <weizardry@gmail.com <mailto:weizardry@gmail.com>>
> wrote:
>
> Hello everyone,
>
> In Gnu Radio 3.10, how to set a variable in a C++ OOT block that can be adjusted
> dynamically by a QT GUI range?
> I did in a .h file:
>   Private:
>     float _param;
>   Public:
>     void set_param(float param) {_param = param;}
> and in the impl.cc file:
>   _param = param;
>
> anywhere else I need to change? I just tried before in Gnu Radio 3.7, and now I am
> very lost with the new version.
>
> Thank you very much.
>
> Regards,
> Wei
>
>

Re: Runtime Frequency Adjustment via ZMQ - Format Error

Hi Muhammad,

kind of intuitively, what you show us isn't sufficient to help you; what you put in on the
other end doesn't seem to be valid PMT. So, you will need to show us how you generate the
PMT messages that you send in via ZMQ.

Best regards,
Marcus

On 4/22/25 7:04 PM, Muhammad Anas wrote:
> Dear Community,
>
> I want to change the freq from another applicatio during runtime using zmq, I have tried
> this by setting the default freq variable to 10, but the message coming from zmq is not
> converting to appropriate format. Could you please help me to rectify this issue?
> terminal output:
> sub_msg_source :error: Invalid PMT message: pmt::deserialize: malformed input stream, tag
> value = : 51
> sub_msg_source :error: Invalid PMT message: pmt::deserialize: malformed input stream, tag
> value = : 51
> sub_msg_source :error: Invalid PMT message: pmt::deserialize: malformed input stream, tag
> value = : 50
> ....
>
> Regards
> Muhammad Anas

Runtime Frequency Adjustment via ZMQ - Format Error

Dear Community,

I want to change the freq from another applicatio during runtime using zmq, I have tried this by setting the default freq variable to 10, but the message coming from zmq is not converting to appropriate format. Could you please help me to rectify this issue?
terminal output:
sub_msg_source :error: Invalid PMT message: pmt::deserialize: malformed input stream, tag value = : 51
sub_msg_source :error: Invalid PMT message: pmt::deserialize: malformed input stream, tag value = : 51
sub_msg_source :error: Invalid PMT message: pmt::deserialize: malformed input stream, tag value = : 50
....  

Regards
Muhammad Anas

Re: Dynamic variables in C++ OOT for Gnu Radio 3.10

And I have added in the .yml file: 

callbacks:

- set_param(${param})

But still the value can't be changed.

On Tue, 22 Apr 2025 at 15:16, Huang Wei <weizardry@gmail.com> wrote:

Hello everyone,

In Gnu Radio 3.10, how to set a variable in a C++ OOT block that can be adjusted dynamically by a QT GUI range?

I did in a .h file:

  Private:

    float _param;

  Public:

    void set_param(float param) {_param = param;}

and in the impl.cc file:

  _param = param;

anywhere else I need to change? I just tried before in Gnu Radio 3.7, and now I am very lost with the new version.

Thank you very much.

Regards,

Wei

Dynamic variables in C++ OOT for Gnu Radio 3.10

Hello everyone,

In Gnu Radio 3.10, how to set a variable in a C++ OOT block that can be adjusted dynamically by a QT GUI range?

I did in a .h file:

  Private:

    float _param;

  Public:

    void set_param(float param) {_param = param;}

and in the impl.cc file:

  _param = param;

anywhere else I need to change? I just tried before in Gnu Radio 3.7, and now I am very lost with the new version.

Thank you very much.

Regards,

Wei

Re: GnuRadio4 build on msys2 / ucrt64

Thanks John,

I will start tomorrow morning trying to categorize the issues I had
getting it running.

Chris

On Mon, Apr 21, 2025 at 5:05 PM John Sallay <jasallay@gmail.com> wrote:
>
> I think it would be great to submit issues and PRs for windows. I don't believe that we have any test infrastructure set up for Windows, but it will be less painful to get it working the sooner we address these issues.
>
> On Mon, Apr 21, 2025, 4:41 PM Chris Gorman <chrisjohgorman@gmail.com> wrote:
>>
>> Hello All,
>>
>> I just spent the weekend getting my feet wet with gnuradio4 trying to
>> build it under Windows (msys2 / ucrt64). I have a small patch (20k)
>> that when applied to the gnuradio4 tree puts enough logic in for it to
>> build on my machine. I chose ucrt64 instead of mingw64 because there
>> was an emscripten package for it and I assumed it would be necessary
>> for a native build. (I now realize that emscripten is only necessary
>> for wasm builds, and I am not familiar enough with wasm to try it
>> yet.)
>>
>> I have a 55% test coverage pass on the build I made and wanted to log
>> some bugs based on my build experience. I wanted to ask here first if
>> there was interest in my writing some bugs for GnuRadio 4 under
>> Windows or is that something to save for much later in its development
>> cycle?
>>
>> Best regards,
>>
>> Chris
>>

Re: GnuRadio4 build on msys2 / ucrt64

I think it would be great to submit issues and PRs for windows. I don't believe that we have any test infrastructure set up for Windows, but it will be less painful to get it working the sooner we address these issues.

On Mon, Apr 21, 2025, 4:41 PM Chris Gorman <chrisjohgorman@gmail.com> wrote:

Hello All,

I just spent the weekend getting my feet wet with gnuradio4 trying to
build it under Windows (msys2 / ucrt64).  I have a small patch  (20k)
that when applied to the gnuradio4 tree puts enough logic in for it to
build on my machine.  I chose ucrt64 instead of mingw64 because there
was an emscripten package for it and I assumed it would be necessary
for a native build.  (I now realize that emscripten is only necessary
for wasm builds, and I am not familiar enough with wasm to try it
yet.)

I have a 55% test coverage pass on the build I made and wanted to log
some bugs based on my build experience.  I wanted to ask here first if
there was interest in my writing some bugs for GnuRadio 4 under
Windows or is that something to save for much later in its development
cycle?

Best regards,

Chris

GnuRadio4 build on msys2 / ucrt64

Hello All,

I just spent the weekend getting my feet wet with gnuradio4 trying to
build it under Windows (msys2 / ucrt64). I have a small patch (20k)
that when applied to the gnuradio4 tree puts enough logic in for it to
build on my machine. I chose ucrt64 instead of mingw64 because there
was an emscripten package for it and I assumed it would be necessary
for a native build. (I now realize that emscripten is only necessary
for wasm builds, and I am not familiar enough with wasm to try it
yet.)

I have a 55% test coverage pass on the build I made and wanted to log
some bugs based on my build experience. I wanted to ask here first if
there was interest in my writing some bugs for GnuRadio 4 under
Windows or is that something to save for much later in its development
cycle?

Best regards,

Chris

Re: QStandardPaths: wrong permissions on runtime directory /run/user/1000 (was: Discuss-gnuradio Digest, Vol 270, Issue 17)

Hi Gary,

awesome, thank you for the description!

On 4/18/25 7:26 PM, gary garcia wrote:
> when I run the flowgraph
> it produces the errors I have listed earlier and then the flowgraph stops
> and I am back in the QT GUI editor
>
I think you mean GRC, right?

> when I run the chmod command the first error goes away and the others remain
> when I replace the audio source with a signal generator the flowgraph simulation runs
>
> I need to install pulseaudio into my ubuntu system and then connect that to the audio block

If anything, you need to install a Pulseaudio *natively on windows*, so your Ubuntu WSL2
machine can connect to it via (virtual) network.
I haven't run GNU Radio on WSL2.

Very very honest and innocent question: why did you take the route of installing GNU Radio
in WSL2 on your Windows machine?
It's usually much easier to just install it on Windows directly - we have an installer for
that – and then it can talk to the Windows audio system directly.

Best regards,
Marcus

[Help Needed] USRP File Transmission Using GMSK - Tag Gap Error & No Reception

Dear GNU Radio Community,

I hope you're doing well. I am currently working on a project where I'm trying to transmit a text file from one USRP device to another using GNU Radio Companion. 

System Setup:

Hardware:

- 2x USRP N210 devices

- Basic TX/RX daughterboards

- Separate TX and RX antennas

- Clock/Time source: Mimo cable

Transmission Flowgraph:

- File Source (repeat = yes / no, tried both)

- Head block

- Stream to Tagged Stream (packet_len)

- Repack Bits (8 to 1)

- GMSK Mod

- USRP Sink

Receiver Flowgraph:

- USRP Source

- GMSK Demod

- Repack Bits (1 to 8)

- File Sink

USRP Configuration:

- Center Frequency: 145 MHz (within board range)

- Sample Rate: 500k

- Gain: 28 dB

Problem Description

When I run the transmitter flowgraph, I can see the signal in the frequency display, but the receiver does not seem to capture any data.

In addition, I'm getting the following recurring error in the console: "usrp_sink: error: tag gap (nitems_read = 1024) no more items to send in current burst, but got 3072 more items, dropping them."

After this, the simulation hangs and I am unable to stop the flowgraph normally — I have to force quit GNU Radio Companion.

When I disable "repeat" in the File Source, the signal disappears altogether, and nothing I can see on the transmission side graph.

My Questions:

1. Could you help me understand the root cause of the "tag gap" error and what's actually happening?

2. Is my approach to the flowgraph design correct for this kind of simple file-based digital communication?

3. Could this be an issue related to packet formatting or tagged stream mismatch?

4. Are there known limitations when using Basic TX/RX boards with GMSK in GNU Radio for such tasks?

I have attached my `.grc` files for both the TX and RX sides for reference (or will share them via link if attachments aren't allowed).

I understand that debugging full flowgraphs may be beyond the scope here, but I would appreciate any pointers on what I might be doing wrong or how I could better debug this issue.

Thank you in advance for your time and support!

Best Regards,

Namira Tahsin

Re: Discuss-gnuradio Digest, Vol 270, Issue 17

when I run the flowgraph

it produces the errors I have listed earlier and then the flowgraph stops 

and I am back in the QT GUI editor

when I run the chmod command the first error goes away and the others remain

when I replace the audio source with a signal generator the flowgraph simulation runs

I need to install pulseaudio into my ubuntu system and then connect that to the audio block

So I believe I know my next steps, 

I most likely will not be able to do these next steps for a couple of days

On Fri, Apr 18, 2025 at 9:03 AM <discuss-gnuradio-request@gnu.org> wrote:

Send Discuss-gnuradio mailing list submissions to
        discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
        discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: QStandardPaths: wrong permissions on runtime directory
      /run/user/1000 (Marcus Müller)


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

Message: 1
Date: Fri, 18 Apr 2025 13:58:05 +0200
From: Marcus Müller <mmueller@gnuradio.org>
To: discuss-gnuradio@gnu.org
Subject: Re: QStandardPaths: wrong permissions on runtime directory
        /run/user/1000
Message-ID: <f165f153-a74d-48cc-9d3d-093e1d26ff2e@gnuradio.org>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Gary,
you seem to be misunderstanding me :)

Can you please tell me what does not work. That's not the same as telling us what errors
are printed. To make a comparison: you call a car mechanic. The mechanic asks
"What is wrong with your car?"
"Well, the two red LEDs in the dashboard are on"
"But what doesn't work?"
"the two red LEDs in the dashboard are on"
"Please tell me how your car actually doesn't function?"
"the two red LEDs in the dashboard: they are on"

See what I mean? The car mechanic would want to know whether your car still starts, or
drives, whether it behaves strangely when you accelerate or break or something, yet you're
only telling her or him that the lights are on.

Can you please tell me what does not work?

Best regards,
Marcus

On 4/16/25 7:01 PM, gary garcia wrote:
>   Thanks for all the help.
>
> First, running chmod 700 /run/user/1000
> corrected the QStandardPaths: wrong permissions issue.
>
> Now when I run the simulation I get the following errors
>
> Qt GUI: Could not restore geometry: restoreGeometry(self, Union[QByteArray, bytes,
> bytearray]): argument 1 has unexpected type 'NoneType'
>   ( I have checked all the blocks and cannot find any "NoneType" arguments, the QT GUI
> does not indicate any errors)
>
> ( not looked into the following errors yet )
>
> ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Timeout
>
> audio_alsa_source :error: [default]: Connection refused
> Traceback (most recent call last):
>    File "/home/jammy/radio_lessons/RTTY_receive.py", line 341, in <module>
>      main()
>    File "/home/jammy/radio_lessons/RTTY_receive.py", line 319, in main
>      tb = top_block_cls()
>    File "/home/jammy/radio_lessons/RTTY_receive.py", line 222, in __init__
>      self.audio_source_0 = audio.source(samp_rate, '', True)
> RuntimeError: audio_alsa_source
>
>  >>> Done (return code 1)
> --
> gary garcia
> gary.garcia1@gmail.com <mailto:gary.garcia1@gmail.com>
> (858)442-9317




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

Subject: Digest Footer

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


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

End of Discuss-gnuradio Digest, Vol 270, Issue 17
*************************************************

--

gary garcia
gary.garcia1@gmail.com
(858)442-9317

Re: QStandardPaths: wrong permissions on runtime directory /run/user/1000

Hi Gary,
you seem to be misunderstanding me :)

Can you please tell me what does not work. That's not the same as telling us what errors
are printed. To make a comparison: you call a car mechanic. The mechanic asks
"What is wrong with your car?"
"Well, the two red LEDs in the dashboard are on"
"But what doesn't work?"
"the two red LEDs in the dashboard are on"
"Please tell me how your car actually doesn't function?"
"the two red LEDs in the dashboard: they are on"

See what I mean? The car mechanic would want to know whether your car still starts, or
drives, whether it behaves strangely when you accelerate or break or something, yet you're
only telling her or him that the lights are on.

Can you please tell me what does not work?

Best regards,
Marcus

On 4/16/25 7:01 PM, gary garcia wrote:
>  Thanks for all the help.
>
> First, running chmod 700 /run/user/1000
> corrected the QStandardPaths: wrong permissions issue.
>
> Now when I run the simulation I get the following errors
>
> Qt GUI: Could not restore geometry: restoreGeometry(self, Union[QByteArray, bytes,
> bytearray]): argument 1 has unexpected type 'NoneType'
>  ( I have checked all the blocks and cannot find any "NoneType" arguments, the QT GUI
> does not indicate any errors)
>
> ( not looked into the following errors yet )
>
> ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Timeout
>
> audio_alsa_source :error: [default]: Connection refused
> Traceback (most recent call last):
>   File "/home/jammy/radio_lessons/RTTY_receive.py", line 341, in <module>
>     main()
>   File "/home/jammy/radio_lessons/RTTY_receive.py", line 319, in main
>     tb = top_block_cls()
>   File "/home/jammy/radio_lessons/RTTY_receive.py", line 222, in __init__
>     self.audio_source_0 = audio.source(samp_rate, '', True)
> RuntimeError: audio_alsa_source
>
> >>> Done (return code 1)
> --
> gary garcia
> gary.garcia1@gmail.com <mailto:gary.garcia1@gmail.com>
> (858)442-9317