Hi Robert,
Glad to hear it works for you. I thought about your problem, and
wondered if I should also give you an explanation on how to fix it
permanently. (Until your next GNU Radio update.) It's a simple fix,
so I'll describe the steps needed to fix it.
On ubuntu run ...
dpkg -L gnuradio | grep util_functions.py
(Or if you were on arch like me, run pacman -Ql gnuradio | grep
util_functions.py.)
This will find the file you need to edit to fix the problem. On my
arch system it's
/usr/lib/python3.13/site-packages/gnuradio/modtool/tools/util_functions.py
Edit this file with your favourite text editor, but you must be root
when you edit this file. (So be very careful.) Run ...
sudo <editor_name>
/usr/lib/python3.13/site-packages/gnuradio/modtool/tools/util_functions.py
Go down to line 45 in the file. The line should be ...
modified_last = last_line + '\n'
Change it to ...
modified_last = last_line + newline + '\n'
Save and exit the file.
The next time you create a python module with gr_modtool, it should
work without the need to edit __init__.py.
All the best,
Chris
On Fri, Jan 17, 2025 at 3:20 PM Robert Heerekop
<robertheerekop@gmail.com> wrote:
>
> Chris, thanks a lot for taking the time to answer my question.
> I understand your explanation and
> Yes, your work-a-round works perfectly here and you enabled me to proceed with my next steps.
>
>
> Op wo 15 jan 2025 om 19:19 schreef Chris Gorman <chrisjohgorman@gmail.com>:
>>
>> Hi Robert,
>>
>> There is a bug in gnuradio 3.10.11.0 with the gr_modtool add command.
>> It was rewritten and a small code mistake causes the error you're
>> experiencing. It has been fixed in the main branch, so the next
>> iteration of gnuradio should work as described in the tutorial.
>>
>> When gr_modtool add is run during the tutorial, it is supposed to edit
>> the file ...
>>
>> python/customModule/__init__.py
>>
>> and add the line ...
>>
>> from .addSubSelect import addSubSelect
>>
>> to __init__.py.
>>
>> In 3.10.11.0 it doesn't do this. It creates the space for the python
>> import, but forgets to add the command. So how to get around this.
>> The simplest way is to add the 'from .module_name import module_name'
>> line to __init__.py file in the space created near the end of the
>> file, under the comment # import any pure python here. Then when you
>> go to build the program the build will succeed. I recommend removing
>> the build directory and creating a new one before restarting the build
>> process.
>>
>> So make the changes to __init__.py, then from the gr-customModule directory ...
>>
>> rm -rf build
>> mkdir build && cd build
>> cmake ..
>>
>> If I recall correctly, this shouldn't affect the building of the C++
>> OOT modules.
>>
>> Let me know if you run into any more obstacles with this.
>>
>> Best regards,
>>
>> Chris
>>
>>
>>
>>
>> On Tue, Jan 14, 2025 at 5:31 AM Robert Heerekop
>> <robertheerekop@gmail.com> wrote:
>> >
>> > Thanks for providing all the documentation and tutorials.
>> > They are really usefull for beginners like me.
>> > I'm trying to learn and following the tutorials but I got stuck in "Creating Python OOT with gr-modtool"
>> >
>> > I keep facing the following error message:
>> >
>> > "AttributeError: module 'gnuradio.customModule' has no attribute 'addSubSelect'"
>> >
>> > Question:
>> > I wonder if I make a mistake or is there something wrong with my (freshly installed) system setup (Ubuntu 24.10 GRC3.10.11.0) ?
>> > Thanks in advance for helping me out, guidance, tips or tricks!
>> >
>> > Robert
>> >
>> > This is the complete log:
>> > <<< Welcome to GNU Radio Companion 3.10.11.0 >>>
>> > Block paths:
>> > /home/robert/.local/state/gnuradio
>> > /usr/share/gnuradio/grc/blocks
>> > /usr/local/share/gnuradio/grc/blocks
>> > Loading: "/home/robert/My_First-block.grc"
>> > >>> Done
>> > Loading: "/home/robert/Creating_Python_OOT2.grc"
>> > >>> Done
>> > Loading: "/home/robert/Creating_Python_OOT.grc"
>> > >>> Done
>> > Generating: "/home/robert/default.py"
>> > Executing: /usr/bin/python3 -u /home/robert/default.py
>> > QSocketNotifier: Can only be used with threads started with QThread
>> > Traceback (most recent call last):
>> > File "/home/robert/default.py", line 186, in <module>
>> > main()
>> > File "/home/robert/default.py", line 163, in main
>> > tb = top_block_cls()
>> > ^^^^^^^^^^^^^^^
>> > File "/home/robert/default.py", line 124, in __init__
>> > self.customModule_addSubSelect_0 = customModule.addSubSelect(True)
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^
>> > AttributeError: module 'gnuradio.customModule' has no attribute 'addSubSelect'
>> > >>> Done (return code 1)
>> >
>> >
Friday, January 17, 2025
Thursday, January 16, 2025
Re: Receiving serial data
This is functionality that I'm going to need in the not too distant future. I haven't yet got to that point, so I'm guessing, but I suspect that you can use a file source / sink and point it at a serial port:
- /dev/ttyS0 (serial port)
- /dev/ttyUSB0 (serial over USB)
- /dev/ttyACM0 (serial over USB)
Alternatively, you can use your own Python block and interact with a serial port however you want to.
Onno
On Thu, 16 Jan 2025 at 22:18, Muhammad Anas <anasg8274@gmail.com> wrote:
Dear GNU Radio Community,Is there any method for receiving data serially from another GUI application other than GRC using xmlrpc/zmq blocks. I want to control GRC parameters from another application serially in runtime.RegardsMuhammed Anas
Re: DVBS2 TX
The output of the Physical Layer Framer block is already interpolated by 2X with zero stuffing.
https://github.com/gnuradio/gnuradio/blob/main/gr-dtv/lib/dvbs2/dvbs2_physical_cc_impl.cc#L835
Ron
On 1/16/25 13:22, othman hijazi wrote:
Hello everybody ,
Iam trying to build a TX DVBS2 ,QPSK,in GNUradio , and iam getting after the decimating cosine filter on the constellation sink a 4 dots plus a dot in zero x,y .
What is expecting a clean constellation with the 4 dots only , but keep getting an additional one in zero x,y ....is there an explanation for this ? what i need to do to get a clean 4 dots only four
Dots on the constellation sink? If anybody can guide me plz.
I tried to add a dc block,delay before or after interpolation rrc filter . but no change .
I did attached a screenshot for the constellation sink and blocks .
Thanks in advance .Best regards,othman
Sent from Outlook
Re: Reducing rare underflows to zero occurrences
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEOn0gFAd3OQG8ow6EtFwrk3lBwykFAmeJfwAACgkQtFwrk3lB
wylsbhAAm2MgI5tbBfWvjBIxedRuEZyroit8Vs8tCGcODlrNOzXYR0B3dfwgm9IN
iAdZI2A+gBdQtfoij3IW6zXKwuAme4QUbrGLyqKXa5a777NVDuFTV4m9/1IZqXY4
53IbO0xyr8Pi20ZKo5lM1Y6Lhbv+h+V4MJBvuSWD9B1ixRb0nJMg5QojVb9SA4tO
Bcdt8zwBdJ37OtLh5SANU/3ETKYZuYapAnrbQEI9YTd2jcSBYNuY4RrHNHzrckVc
zO+TJLkpNvsSYNTlspHCMKNvXYXIT7dKbrr1TQ6YL46An/eBzWLZFX+RVjoP09Dq
i1NR1Tl8Exn5pUPKfMoDlqrAwy68z8MCx6kRuWizOXKAN33VN3ONUuMBxfnlIvqQ
rgbWeayH/AeSEfX1pxwjj4ULjSKMBqhpap6mYt714gS0LzhskO0DHOFgYW9hDdDv
125N9UidmH55EV3fgRM7V/5Y1JqgJ54Y8mrmWP8pdThnpdsjBdscnOCX+LCHj5zn
g2OjbwgBHwJcWtUYmoOO6OOv/8U8xCzzzEx3SNKK0bLP7YCjQUFNam6Phny6JRBL
XeDBZsE51iehyesCqVzfMAGW6qhnP26wp0gqG9a3exgFm4X6kDXPeJoKqW8dobge
dUXQ8GLZ4ElyZXe7UGECkVQxg5YQnJnjuKWEV4QyRq+Ovh5KEug=
=2VID
-----END PGP SIGNATURE-----
Hi Chad,
Something that you can do to monitor the problem is to look in
/proc/net/udp. This will show you the fill level of kernel UDP receive
buffers. If you've set the buffer size to 32 MiB as recommended by the
performance tuning tips, usually these sporadic drops are the result of
the flowgraph consuming data at a rate slightly lower than the nominal
sample rate for multiple seconds, rather than a brief but larger
performance reduction. If this is the case, you can see how the buffer
fill level slowly increases over the course of several seconds until the
buffer fills up and packets are dropped. Looking at this won't solve
your problem, but at least it will give you a way to monitor if you do
some changes to try to improve the performance.
Best,
Daniel.
On 16/01/2025 19:38, Chad Spooner wrote:
> All:
>
> I'm developing a comm system involving three SDRs: transmit, channel
> effects, and receiver.
>
> The channel SDR is controlled by a flowgraph that has various options
> for the channel: AWGN (h(\tau) = \delta(\tau)), LTI, and a couple time-
> variant frequency-selective channel models.
>
> I need to run the full three-SDR system over long periods of time to get
> stable average values for system-performance parameters.
>
> My problem is that the channel flowgraph reports underflows on the order
> of every hundred seconds or so (sometimes much less). I've tracked down
> these rare underflows in the channel to transient problems in the
> receiver flowgraph.
>
> So I put together a minimum flowgraph that shows the problem, which is
> attached. When I run it, I get output like this:
>
> [INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> usrp_source :info: set_min_output_buffer on block 1 to 2097152
> usrp_sink :info: set_min_output_buffer on block 2 to 2097152
> mmse_resampler_cc :info: set_min_output_buffer on block 4 to 2097152
> fir_filter_blk<IN_T,OUT_T,TAP_T> :info: set_min_output_buffer on
> block 5 to 2097152
> multiply_cc :info: set_min_output_buffer on block 9 to 2097152
> sig_source :info: set_min_output_buffer on block 8 to 2097152
> add_cc :info: set_min_output_buffer on block 6 to 2097152
> fastnoise_source :info: set_min_output_buffer on block 7 to 2097152
> *Uusrp_sink :error: In the last 579300 ms, 1 underflows occurred.
> Uusrp_sink :error: In the last 256008 ms, 1 underflows occurred.
> usrp_sink :error: In the last 84992 ms, 1 underflows occurred.
> UUusrp_sink :error: In the last 128008 ms, 1 underflows occurred.*
>
> The PSD of the filtered input signal appears correctly on a spectrum
> analyzer.
>
> System Information:
>
> 24-core Intel i9 system
> Ubuntu 22.04.5 LTS, kernel 5.19.0-46-generic #47~22.04.1-Ubuntu
> gnuradio 3.10.1.1
> UHD 4.1.0.5-3
>
> I've taken some pains to optimize the OS settings for gnuradio/UHD along
> the lines suggested by the online tips at
>
> https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
>
> I've also tinkered with the minoutbuf parameter in the various blocks.
>
> Any advice?
>
> Thanks,
>
> Chad
> cyclostationary.blog
> cmspooner@nwra.com
>
>
>
>
>
> --
> Chad M. Spooner, PhD
> NorthWest Research Associates
> 149 Bonifacio Place, Suite 200
> Monterey, CA 93940
> cmspooner@nwra.com
> 831 521 6743
> NWRA Scientist/Engineer, VP, BoD
> cyclostationary.blog
>
iQIzBAEBCAAdFiEEOn0gFAd3OQG8ow6EtFwrk3lBwykFAmeJfwAACgkQtFwrk3lB
wylsbhAAm2MgI5tbBfWvjBIxedRuEZyroit8Vs8tCGcODlrNOzXYR0B3dfwgm9IN
iAdZI2A+gBdQtfoij3IW6zXKwuAme4QUbrGLyqKXa5a777NVDuFTV4m9/1IZqXY4
53IbO0xyr8Pi20ZKo5lM1Y6Lhbv+h+V4MJBvuSWD9B1ixRb0nJMg5QojVb9SA4tO
Bcdt8zwBdJ37OtLh5SANU/3ETKYZuYapAnrbQEI9YTd2jcSBYNuY4RrHNHzrckVc
zO+TJLkpNvsSYNTlspHCMKNvXYXIT7dKbrr1TQ6YL46An/eBzWLZFX+RVjoP09Dq
i1NR1Tl8Exn5pUPKfMoDlqrAwy68z8MCx6kRuWizOXKAN33VN3ONUuMBxfnlIvqQ
rgbWeayH/AeSEfX1pxwjj4ULjSKMBqhpap6mYt714gS0LzhskO0DHOFgYW9hDdDv
125N9UidmH55EV3fgRM7V/5Y1JqgJ54Y8mrmWP8pdThnpdsjBdscnOCX+LCHj5zn
g2OjbwgBHwJcWtUYmoOO6OOv/8U8xCzzzEx3SNKK0bLP7YCjQUFNam6Phny6JRBL
XeDBZsE51iehyesCqVzfMAGW6qhnP26wp0gqG9a3exgFm4X6kDXPeJoKqW8dobge
dUXQ8GLZ4ElyZXe7UGECkVQxg5YQnJnjuKWEV4QyRq+Ovh5KEug=
=2VID
-----END PGP SIGNATURE-----
Hi Chad,
Something that you can do to monitor the problem is to look in
/proc/net/udp. This will show you the fill level of kernel UDP receive
buffers. If you've set the buffer size to 32 MiB as recommended by the
performance tuning tips, usually these sporadic drops are the result of
the flowgraph consuming data at a rate slightly lower than the nominal
sample rate for multiple seconds, rather than a brief but larger
performance reduction. If this is the case, you can see how the buffer
fill level slowly increases over the course of several seconds until the
buffer fills up and packets are dropped. Looking at this won't solve
your problem, but at least it will give you a way to monitor if you do
some changes to try to improve the performance.
Best,
Daniel.
On 16/01/2025 19:38, Chad Spooner wrote:
> All:
>
> I'm developing a comm system involving three SDRs: transmit, channel
> effects, and receiver.
>
> The channel SDR is controlled by a flowgraph that has various options
> for the channel: AWGN (h(\tau) = \delta(\tau)), LTI, and a couple time-
> variant frequency-selective channel models.
>
> I need to run the full three-SDR system over long periods of time to get
> stable average values for system-performance parameters.
>
> My problem is that the channel flowgraph reports underflows on the order
> of every hundred seconds or so (sometimes much less). I've tracked down
> these rare underflows in the channel to transient problems in the
> receiver flowgraph.
>
> So I put together a minimum flowgraph that shows the problem, which is
> attached. When I run it, I get output like this:
>
> [INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> usrp_source :info: set_min_output_buffer on block 1 to 2097152
> usrp_sink :info: set_min_output_buffer on block 2 to 2097152
> mmse_resampler_cc :info: set_min_output_buffer on block 4 to 2097152
> fir_filter_blk<IN_T,OUT_T,TAP_T> :info: set_min_output_buffer on
> block 5 to 2097152
> multiply_cc :info: set_min_output_buffer on block 9 to 2097152
> sig_source :info: set_min_output_buffer on block 8 to 2097152
> add_cc :info: set_min_output_buffer on block 6 to 2097152
> fastnoise_source :info: set_min_output_buffer on block 7 to 2097152
> *Uusrp_sink :error: In the last 579300 ms, 1 underflows occurred.
> Uusrp_sink :error: In the last 256008 ms, 1 underflows occurred.
> usrp_sink :error: In the last 84992 ms, 1 underflows occurred.
> UUusrp_sink :error: In the last 128008 ms, 1 underflows occurred.*
>
> The PSD of the filtered input signal appears correctly on a spectrum
> analyzer.
>
> System Information:
>
> 24-core Intel i9 system
> Ubuntu 22.04.5 LTS, kernel 5.19.0-46-generic #47~22.04.1-Ubuntu
> gnuradio 3.10.1.1
> UHD 4.1.0.5-3
>
> I've taken some pains to optimize the OS settings for gnuradio/UHD along
> the lines suggested by the online tips at
>
> https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
>
> I've also tinkered with the minoutbuf parameter in the various blocks.
>
> Any advice?
>
> Thanks,
>
> Chad
> cyclostationary.blog
> cmspooner@nwra.com
>
>
>
>
>
> --
> Chad M. Spooner, PhD
> NorthWest Research Associates
> 149 Bonifacio Place, Suite 200
> Monterey, CA 93940
> cmspooner@nwra.com
> 831 521 6743
> NWRA Scientist/Engineer, VP, BoD
> cyclostationary.blog
>
DVBS2 TX
Hello everybody ,
Iam trying to build a TX DVBS2 ,QPSK,in GNUradio , and iam getting after the decimating cosine filter on the constellation sink a 4 dots plus a dot in zero x,y .
What is expecting a clean constellation with the 4 dots only , but keep getting an additional one in zero x,y ....is there an explanation for this ? what i need to do to get a clean 4 dots only four
Dots on the constellation sink? If anybody can guide me plz.
I tried to add a dc block,delay before or after interpolation rrc filter . but no change .
I did attached a screenshot for the constellation sink and blocks .
Thanks in advance .
Best regards,
othman
Sent from Outlook
Reducing rare underflows to zero occurrences
All:
I'm developing a comm system involving three SDRs: transmit, channel effects, and receiver.
The channel SDR is controlled by a flowgraph that has various options for the channel: AWGN (h(\tau) = \delta(\tau)), LTI, and a couple time-variant frequency-selective channel models.
I need to run the full three-SDR system over long periods of time to get stable average values for system-performance parameters.
My problem is that the channel flowgraph reports underflows on the order of every hundred seconds or so (sometimes much less). I've tracked down these rare underflows in the channel to transient problems in the receiver flowgraph.
So I put together a minimum flowgraph that shows the problem, which is attached. When I run it, I get output like this:
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
usrp_source :info: set_min_output_buffer on block 1 to 2097152
usrp_sink :info: set_min_output_buffer on block 2 to 2097152
mmse_resampler_cc :info: set_min_output_buffer on block 4 to 2097152
fir_filter_blk<IN_T,OUT_T,TAP_T> :info: set_min_output_buffer on block 5 to 2097152
multiply_cc :info: set_min_output_buffer on block 9 to 2097152
sig_source :info: set_min_output_buffer on block 8 to 2097152
add_cc :info: set_min_output_buffer on block 6 to 2097152
fastnoise_source :info: set_min_output_buffer on block 7 to 2097152
Uusrp_sink :error: In the last 579300 ms, 1 underflows occurred.
Uusrp_sink :error: In the last 256008 ms, 1 underflows occurred.
usrp_sink :error: In the last 84992 ms, 1 underflows occurred.
UUusrp_sink :error: In the last 128008 ms, 1 underflows occurred.
The PSD of the filtered input signal appears correctly on a spectrum analyzer.
System Information:
24-core Intel i9 system
Ubuntu 22.04.5 LTS, kernel 5.19.0-46-generic #47~22.04.1-Ubuntu
gnuradio 3.10.1.1
UHD 4.1.0.5-3
I've taken some pains to optimize the OS settings for gnuradio/UHD along the lines suggested by the online tips at
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
I've also tinkered with the minoutbuf parameter in the various blocks.
Any advice?
Thanks,
Chadcyclostationary.blog
cmspooner@nwra.com
-- Chad M. Spooner, PhD NorthWest Research Associates 149 Bonifacio Place, Suite 200 Monterey, CA 93940 cmspooner@nwra.com 831 521 6743 NWRA Scientist/Engineer, VP, BoD cyclostationary.blog
Receiving serial data
Dear GNU Radio Community,
Is there any method for receiving data serially from another GUI application other than GRC using xmlrpc/zmq blocks. I want to control GRC parameters from another application serially in runtime.
Regards
Muhammed Anas
Subscribe to:
Posts (Atom)