Re: qa_qtgui (Failed)-Segmentation fault (core dumped)
Hi Isaac, On 30/11/2021 07.50, isaac mario tupac davila wrote: > So I've run valgrind -v ctest -V -R qa_qtgui This way you are running the ctest under valgrind and not the test.You need to open the qa_qtgui_test.sh file and on the last line add valgrind before python. As this test is a python script you will need to run python under valgrind. /home/soporte/GR-workarea/gnuradio/build/gr-qtgui/python/qtgui/qa_qtgui_test.sh valgrind /usr/bin/python3 -B /home/soporte/GR-workarea/gnuradio/gr-qtgui/python/qtgui/qa_qtgui.py Regards, Vasil
Re: Problems when passing messages to a source block
Jeff,
Are you mailing with yourself?
wt., 30 lis 2021 o 00:46 Jeff Long napisał(a):
> Sounds good. Only look at the C++ to figure out the general idea. I'd
> learn Python threading first in a standalone program so you're not learning
> (debugging) GR and python threading at the same time. Good luck - let us
> know how it goes.
>
> Also, please respond to the mailing list so everyone can benefit from the
> conversation.
>
> On Mon, Nov 29, 2021 at 5:11 PM Michelle wrote:
>
>> Hi Jeff,
>>
>> thank you for your help and sorry for the delay, I was in class.
>>
>> it is now that I start to work on it. My first step is to master how the
>> c++ code of the strobe message block work, specially the functions:
>>
>> -bool message_strobe_impl::start()
>>
>> -bool message_strobe_impl::stop()
>>
>> -void message_strobe_impl::run()
>>
>> Then I will implement the python version following your advice. I will
>> write to you to show you the result.
>>
>> Once again thank you, I was really lost.
>>
>> Have a good afternoon.
>>
>> OK, it does work, as long as there is a message port defined and
>> connected in a flowgraph. I was trying too simple an example. You would do
>> your thread management in the start() and stop() functions.
>>
>> """
>> Embedded Python Blocks:
>>
>> Each time this file is saved, GRC will instantiate the first class it
>> finds
>> to get ports and parameters of your block. The arguments to __init__ will
>> be the parameters. All of them are required to have default values!
>> """
>>
>> import numpy as np
>> from gnuradio import gr
>> import pmt
>>
>> class blk(gr.sync_block): # other base classes are basic_block,
>> decim_block, interp_block
>> """Embedded Python Block example - a simple multiply const"""
>>
>> def __init__(self): # only default arguments here
>> """arguments to this function show up as parameters in GRC"""
>> gr.sync_block.__init__(
>> self,
>> name='Embedded Python Block', # will show up in GRC
>> in_sig=[],
>> out_sig=[]
>> )
>> self.message_port_register_out(pmt.intern("msgout"))
>> print('init')
>>
>> def start(self):
>> print('start')
>> return True
>>
>> def stop(self):
>> print('stop')
>> return True
>>
>> On Mon, Nov 29, 2021 at 2:13 PM Jeff Long wrote:
>>
>>> Issue submitted: https://github.com/gnuradio/gnuradio/issues/5358
>>>
>>> On Mon, Nov 29, 2021 at 1:58 PM Jeff Long wrote:
>>>
It does not seem that python blocks can override start() and stop(),
which they should be able to do. So, don't go too far down that path. I do
not see anywhere in the code where this is used or would have been caught.
The embedded blocks are easier, be beware that GRC calls the init
function to learn about the block. Therefore, you don't want any action
taken as a result of a call to init, for instance spawning a thread and
starting to send messages. Embedded python block are sort of a toy that
turned out to be useful. In general, an OOT is a better idea, but an
embedded block can work if it's simple enough.
Maybe someone else has figured this out. With just a quick look, I
don't see how a Message Strobe kind of block can be implemented in python
without start() and stop().
Here's kind of a hack: make a python block with a message handler that
gets a periodic strobe from the existing Message Strobe block. In the
handler, send out the message that you would have sent in the thread.
>>>
qa_qtgui (Failed)-Segmentation fault (core dumped)
Hi I'm trying to install GR 3.8.1.0 from source (cloning). After make the build directory , i run make test and I see the following mistakes: * The following tests FAILED: 41 - qa_volk_32f_s32f_calc_spectral_noise_floor_32f (Failed) 306 - qa_constellation (Failed) 309 - qa_constellation_soft_decoder_cf (Failed) 348 - qa_qtgui (Failed) ** I'd like to solve qa_qtgui. So I've run valgrind -v ctest -V -R qa_qtgui and see: --14261-- REDIR: 0x6459b70 (libc.so.6:memmove) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458e80 (libc.so.6:strncpy) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459e50 (libc.so.6:strcasecmp) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x64588d0 (libc.so.6:strcat) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458eb0 (libc.so.6:rindex) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x645b5a0 (libc.so.6:rawmemchr) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459ce0 (libc.so.6:mempcpy) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459b10 (libc.so.6:bcmp) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458e40 (libc.so.6:strncmp) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458940 (libc.so.6:strcmp) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459c40 (libc.so.6:memset) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6476ed0 (libc.so.6:wcschr) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458de0 (libc.so.6:strnlen) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x64589b0 (libc.so.6:strcspn) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459ea0 (libc.so.6:strncasecmp) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458980 (libc.so.6:strcpy) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459fe0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458ee0 (libc.so.6:strpbrk) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458900 (libc.so.6:index) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6458db0 (libc.so.6:strlen) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x64634a0 (libc.so.6:memrchr) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459ef0 (libc.so.6:strcasecmp_l) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459ae0 (libc.so.6:memchr) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6477c90 (libc.so.6:wcslen) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459190 (libc.so.6:strspn) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459e20 (libc.so.6:stpncpy) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459df0 (libc.so.6:stpcpy) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x645b5d0 (libc.so.6:strchrnul) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459f40 (libc.so.6:strncasecmp_l) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x64ec730 (libc.so.6:__memcpy_chk) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x6459a20 (libc.so.6:strstr) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) --14261-- REDIR: 0x64ec800 (libc.so.6:__memmove_chk) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) ==14261== WARNING: new redirection conflicts with existing -- ignoring it --14261-- old: 0x06549a00 (__memcpy_chk_avx_una) R-> (2030.0) 0x04c395e0 __memcpy_chk --14261-- new: 0x06549a00 (__memcpy_chk_avx_una) R-> (2024.0) 0x04c38fa0 __memmove_chk --14261-- REDIR: 0x6458e10 (libc.so.6:strncat) redirected to 0x4a2c6e0 (_vgnU_ifunc_wrapper) ==14261== WARNING: new redirection conflicts with existing -- ignoring it --14261-- old: 0x06549a00 (__memcpy_chk_avx_una) R-> (2030.0) 0x04c395e0 __memcpy_chk --14261-- new: 0x06549a00 (__memcpy_chk_avx_una) R-> (2024.0) 0x04c38fa0 __memmove_chk ==14261== WARNING: new redirection conflicts with existing -- ignoring it --14261-- old: 0x06549a00 (__memcpy_chk_avx_una) R-> (2030.0) 0x04c395e0 __memcpy_chk --14261-- new: 0x06549a00 (__memcpy_chk_avx_una) R-> (2024.0) 0x04c38fa0 __memmove_chk ==14261== WARNING: new redirection conflicts with existing -- ignoring it --14261-- old: 0x06549a00 (__memcpy_chk_avx_una) R-> (2030.0) 0x04c395e0 __memcpy_chk --14261-- new: 0x06549a00 (__memcpy_chk_avx_una) R-> (2024.0) 0x04c38fa0 __memmove_chk ==14261== WARNING: new redirection conflicts with existing -- ignoring it --14261-- old: 0x06549a00 (__memcpy_chk_avx_una) R-> (2030.0) 0x04c395e0 __memcpy_chk --14261-- new: 0x06549a00 (__memcpy_chk_avx_una) R-> (2024.0)
Re: Variable Config Read and Write Questions
Submitted Issue https://github.com/gnuradio/gnuradio/issues/5359.
On Mon, Nov 29, 2021 at 7:31 PM Jeff Long wrote:
> The Variable Config is definitely a strange one, when used as you are
> using it (read and write to runtime-selectable sections). Here's the code
> it generates for handling a change in section (e.g., toggling between 40
> and 80 in your example). I've created two config variables, freq and lna.
>
> def set_section(self, section):
> self.section = section
> self._freq_config_config = configparser.ConfigParser()
> self._freq_config_config.read('/tmp/testconfig.ini')
> if not self._freq_config_config.has_section(self.section):
> self._freq_config_config.add_section(self.section)
> self._freq_config_config.set(self.section, 'freq', str(self.freq))
> self._freq_config_config.write(open('/tmp/testconfig.ini', 'w'))
> self._lna_config_config = configparser.ConfigParser()
> self._lna_config_config.read('/tmp/testconfig.ini')
> if not self._lna_config_config.has_section(self.section):
> self._lna_config_config.add_section(self.section)
> self._lna_config_config.set(self.section, 'lna', str(self.lna))
> self._lna_config_config.write(open('/tmp/testconfig.ini', 'w'))
> self._section_callback(self.section)
>
> which says it will do exactly what you're seeing. This is the first time
> I've heard of the block, actually, so I'm sure it's not getting much
> attention!
>
> I'll put in an Issue on this. You should probably find another way to do
> what you are thinking of, since I don't think this will be addressed right
> away. Thanks for the report.
>
> On Mon, Nov 29, 2021 at 6:22 PM Elmore's wrote:
>
>> Variable Config
>> ID: I_image_config
>> Section: image_sections[image_chooser]
>> Option: I_image_correct
>> Write Back: I_Gain
>>
>> GUI Range
>> ID: I_Gain
>> Default: I_image_config
>>
>> I found a question similar to this one on the forum but no one answered
>> it so I hope I can get a response to this one.
>>
>> I have shown above my configuration for two blocks in my flowgraph.
>>
>> I wish to write to and read from an INI file with 5 sections.
>>
>> I can successfully write the value of I_Gain to I_image_correct in a
>> single section when I make an adjustment to the I_Gain Range control. I
>> want to use a Chooser with the ID: image_chooser to select another section
>> to write a value of I_Gain to that section. However, the Chooser callback
>> writes the current value of I_Gain immediately to the file without my
>> making a change to I_Gain. This is a major problem if I wish to select a
>> Section that I had already stored a value in. Whatever the current value of
>> I_Gain happens to be is written to the Section. For example: I change
>> I_Gain to 1.1 for Section 40. I then select Section 80 which immediately
>> upon selection has 1.1 written to it. I then select I_Gain = 1.5 which
>> stores that value in Section 80. I then select Section 40 in hopes of using
>> I_Gain = 1.1 but find that in the process of selection the value of I_Gain
>> has changed to 1.5. This makes no sense since it defeats the purpose of
>> saving a configuration in a file.
>>
>> How do I save parameters to different sections without the sections being
>> overwritten?
>>
>> The other main issue is how do I read from the file so that I can set
>> I_Gain when the Section is selected? I don’t see how to do this. The only
>> time I have seen the file read is on initialization. I presume this is due
>> to the fact that I set the default value of I_Gain to I_image_config. I
>> need to to be able to read a value on demand.
>>
>> By the way, I have 3 parameters to save and recall in each of 5 Sections.
>>
>> Any help will be greatly appreciated. I have been wrestling with this
>> issue for quite some time.
>>
>>
>>
>>
>>
>> Virus-free.
>> www.avg.com
>>
>> <#m_8892035469763263520_m_-7819765792157969049_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>
Re: Variable Config Read and Write Questions
The Variable Config is definitely a strange one, when used as you are using
it (read and write to runtime-selectable sections). Here's the code it
generates for handling a change in section (e.g., toggling between 40 and
80 in your example). I've created two config variables, freq and lna.
def set_section(self, section):
self.section = section
self._freq_config_config = configparser.ConfigParser()
self._freq_config_config.read('/tmp/testconfig.ini')
if not self._freq_config_config.has_section(self.section):
self._freq_config_config.add_section(self.section)
self._freq_config_config.set(self.section, 'freq', str(self.freq))
self._freq_config_config.write(open('/tmp/testconfig.ini', 'w'))
self._lna_config_config = configparser.ConfigParser()
self._lna_config_config.read('/tmp/testconfig.ini')
if not self._lna_config_config.has_section(self.section):
self._lna_config_config.add_section(self.section)
self._lna_config_config.set(self.section, 'lna', str(self.lna))
self._lna_config_config.write(open('/tmp/testconfig.ini', 'w'))
self._section_callback(self.section)
which says it will do exactly what you're seeing. This is the first time
I've heard of the block, actually, so I'm sure it's not getting much
attention!
I'll put in an Issue on this. You should probably find another way to do
what you are thinking of, since I don't think this will be addressed right
away. Thanks for the report.
On Mon, Nov 29, 2021 at 6:22 PM Elmore's wrote:
> Variable Config
> ID: I_image_config
> Section: image_sections[image_chooser]
> Option: I_image_correct
> Write Back: I_Gain
>
> GUI Range
> ID: I_Gain
> Default: I_image_config
>
> I found a question similar to this one on the forum but no one answered it
> so I hope I can get a response to this one.
>
> I have shown above my configuration for two blocks in my flowgraph.
>
> I wish to write to and read from an INI file with 5 sections.
>
> I can successfully write the value of I_Gain to I_image_correct in a
> single section when I make an adjustment to the I_Gain Range control. I
> want to use a Chooser with the ID: image_chooser to select another section
> to write a value of I_Gain to that section. However, the Chooser callback
> writes the current value of I_Gain immediately to the file without my
> making a change to I_Gain. This is a major problem if I wish to select a
> Section that I had already stored a value in. Whatever the current value of
> I_Gain happens to be is written to the Section. For example: I change
> I_Gain to 1.1 for Section 40. I then select Section 80 which immediately
> upon selection has 1.1 written to it. I then select I_Gain = 1.5 which
> stores that value in Section 80. I then select Section 40 in hopes of using
> I_Gain = 1.1 but find that in the process of selection the value of I_Gain
> has changed to 1.5. This makes no sense since it defeats the purpose of
> saving a configuration in a file.
>
> How do I save parameters to different sections without the sections being
> overwritten?
>
> The other main issue is how do I read from the file so that I can set
> I_Gain when the Section is selected? I don’t see how to do this. The only
> time I have seen the file read is on initialization. I presume this is due
> to the fact that I set the default value of I_Gain to I_image_config. I
> need to to be able to read a value on demand.
>
> By the way, I have 3 parameters to save and recall in each of 5 Sections.
>
> Any help will be greatly appreciated. I have been wrestling with this
> issue for quite some time.
>
>
>
>
>
> Virus-free.
> www.avg.com
>
> <#m_-7819765792157969049_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
Re: Problems when passing messages to a source block
Sounds good. Only look at the C++ to figure out the general idea. I'd learn
Python threading first in a standalone program so you're not learning
(debugging) GR and python threading at the same time. Good luck - let us
know how it goes.
Also, please respond to the mailing list so everyone can benefit from the
conversation.
On Mon, Nov 29, 2021 at 5:11 PM Michelle wrote:
> Hi Jeff,
>
> thank you for your help and sorry for the delay, I was in class.
>
> it is now that I start to work on it. My first step is to master how the
> c++ code of the strobe message block work, specially the functions:
>
> -bool message_strobe_impl::start()
>
> -bool message_strobe_impl::stop()
>
> -void message_strobe_impl::run()
>
> Then I will implement the python version following your advice. I will
> write to you to show you the result.
>
> Once again thank you, I was really lost.
>
> Have a good afternoon.
>
> OK, it does work, as long as there is a message port defined and connected
> in a flowgraph. I was trying too simple an example. You would do your
> thread management in the start() and stop() functions.
>
> """
> Embedded Python Blocks:
>
> Each time this file is saved, GRC will instantiate the first class it finds
> to get ports and parameters of your block. The arguments to __init__ will
> be the parameters. All of them are required to have default values!
> """
>
> import numpy as np
> from gnuradio import gr
> import pmt
>
> class blk(gr.sync_block): # other base classes are basic_block,
> decim_block, interp_block
> """Embedded Python Block example - a simple multiply const"""
>
> def __init__(self): # only default arguments here
> """arguments to this function show up as parameters in GRC"""
> gr.sync_block.__init__(
> self,
> name='Embedded Python Block', # will show up in GRC
> in_sig=[],
> out_sig=[]
> )
> self.message_port_register_out(pmt.intern("msgout"))
> print('init')
>
> def start(self):
> print('start')
> return True
>
> def stop(self):
> print('stop')
> return True
>
> On Mon, Nov 29, 2021 at 2:13 PM Jeff Long wrote:
>
>> Issue submitted: https://github.com/gnuradio/gnuradio/issues/5358
>>
>> On Mon, Nov 29, 2021 at 1:58 PM Jeff Long wrote:
>>
>>> It does not seem that python blocks can override start() and stop(),
>>> which they should be able to do. So, don't go too far down that path. I do
>>> not see anywhere in the code where this is used or would have been caught.
>>>
>>> The embedded blocks are easier, be beware that GRC calls the init
>>> function to learn about the block. Therefore, you don't want any action
>>> taken as a result of a call to init, for instance spawning a thread and
>>> starting to send messages. Embedded python block are sort of a toy that
>>> turned out to be useful. In general, an OOT is a better idea, but an
>>> embedded block can work if it's simple enough.
>>>
>>> Maybe someone else has figured this out. With just a quick look, I don't
>>> see how a Message Strobe kind of block can be implemented in python without
>>> start() and stop().
>>>
>>> Here's kind of a hack: make a python block with a message handler that
>>> gets a periodic strobe from the existing Message Strobe block. In the
>>> handler, send out the message that you would have sent in the thread.
>>>
>>
Variable Config Read and Write Questions
Variable Config ID: I_image_config Section: image_sections[image_chooser] Option: I_image_correct Write Back: I_Gain GUI Range ID: I_Gain Default: I_image_config I found a question similar to this one on the forum but no one answered it so I hope I can get a response to this one. I have shown above my configuration for two blocks in my flowgraph. I wish to write to and read from an INI file with 5 sections. I can successfully write the value of I_Gain to I_image_correct in a single section when I make an adjustment to the I_Gain Range control. I want to use a Chooser with the ID: image_chooser to select another section to write a value of I_Gain to that section. However, the Chooser callback writes the current value of I_Gain immediately to the file without my making a change to I_Gain. This is a major problem if I wish to select a Section that I had already stored a value in. Whatever the current value of I_Gain happens to be is written to the Section. For example: I change I_Gain to 1.1 for Section 40. I then select Section 80 which immediately upon selection has 1.1 written to it. I then select I_Gain = 1.5 which stores that value in Section 80. I then select Section 40 in hopes of using I_Gain = 1.1 but find that in the process of selection the value of I_Gain has changed to 1.5. This makes no sense since it defeats the purpose of saving a configuration in a file. How do I save parameters to different sections without the sections being overwritten? The other main issue is how do I read from the file so that I can set I_Gain when the Section is selected? I don’t see how to do this. The only time I have seen the file read is on initialization. I presume this is due to the fact that I set the default value of I_Gain to I_image_config. I need to to be able to read a value on demand. By the way, I have 3 parameters to save and recall in each of 5 Sections. Any help will be greatly appreciated. I have been wrestling with this issue for quite some time. -- This email has been checked for viruses by AVG. https://www.avg.com
Re: Gnuradio 3.8 on a Raspberry pi 4 B?
On 11/25/21 5:52 PM, Marcus Müller wrote: Hi Lamar! ... I don't want to get into this again, honestly, we have like six or seven threads on this mailing list. Marcus, Sorry if I come across as a bit abrasive; that's not the intent. Nor am I wanting to overstate the point, or just continue an unproductive conversation ad nauseum. It's really that simple: Stillstand and technical and community Death, or Progress and Breakage. It's a balance to strike, which is why with every release, the poor Maintainer goes and looks into their crystal ball, to see what they can improve without breaking the usability on reasonably old systems for the next release. We're really doing our best to *not* let GNU Radio die, so please understand that as much as I personally like what Glen does, it cannot define GNU Radio's speed. ... Of course it can't define it; not my point. My point is that a part of release balance is migration planning that allows smooth transitions and upgrades. I advocated for that for years for another large project that tended to break things every major version; I maintained the RPM packages for that software for five years, and was perpetually caught in the middle between those who developed the software, expecting users to do various 'things' to upgrade from one version to the next and those users who expected 'rpm -U' to Just Work, which it didn't. So I DO understand and sympathize with the issues on the developer side. But I also believe that breakage should not happen between incremental versions. Since GNUradio is built on Python, using the Python model, I expect breakage between Python 2.x and 3.x; I expect rather less breakage between 3.x and 3.(x+1). That's when as a maintainer, you, responsibly, publicly say that, no, sorry, we're no longer in a position to guarantee the quality of further software releases. I have been in that position; it's not an easy one. And no you can't guarantee that quality as a volunteer. So, please, understand that I might get a bit frustrated by people portraying things like we're letting Glen stand out in the rain. Or that we do things "willy-nilly". We don't. We made sure he has migration options, multiple people are and have been offering help, people are actively trying to help him get his airplay running, even though it's a commercial product that's incompatible by its own choice with our software license. I am familiar with the frustration on both the developers' parts and the users' parts, since I HAVE been caught between. And no I don't believe you're 'letting Glen stand out in the rain' or doing things 'willy-nilly;' that's reading more into what I wrote than is there. I am just stating a fact; even the churn that is necessary muddies the waters. No argument from me that upgrades and progress is necessary; it IS necessary, but what has been lacking (at least the last time I checked; my apologies if this type of document now exists) is a document that outlines the changes required for OOT modules and users programs to migrate from one version to another; better in ways would be a script that can make the edits, although the way of automation is fraught with peril (been there, done that, during the same stint as RPM maintainer). And YES the SDRplay API is way more closed than I would like. And I'm not trying to frustrate anyone; but there IS significant volatility in the GNUradio system that can be very frustrating to users.
Re: Calling blocks directly
This sounds like a very interesting project - but separating out the calls to blocks from the underlying framework is very difficult in GNU Radio for many reasons, but one being that the blocks call back into the scheduler for things like getting the number of items read/written, and updating buffer pointers and such. Separating the block API so the blocks can be used for this purpose (integration of the core signal processing work() calls with external frameworks) is a goal of the GR 4.0 framework (newsched). If you are interested in doing this with newsched (https://github.com/gnuradio/newsched) - we can port more blocks in from GNU Radio that might be of interest. Josh On Mon, Nov 29, 2021 at 2:01 PM Jeff Long wrote: > To do this, you write a "mock" framework that calls the block init, then > calls general_work() or work() with the proper parameters. I'd say you need > to understand the C++ API for blocks pretty well to make this work. How > much of the framework you need to implement will depend on which blocks you > use. > > On Mon, Nov 29, 2021 at 1:28 PM Andra-Maria Ilies < > andramariail...@gmail.com> wrote: > >> Hello, >> >> >> I am trying to write a full-program optimizer for GNURadio flow graphs in >> C++. For this purpose, I need to call GNURadio blocks separately inside my >> program. >> >> >> I have 2 questions: >> >>1. How to directly feed a local vector input to a block? >>2. How can I set a local array as the output array of the used block? >> >> >> I would like to mention that I want to do this directly, without using >> GNU Radio specific functions such as connect(), because I will be using >> only certain blocks, whose operation I find useful for my application. >> >> >> Thank you in advance! >> >> Andra >> >
Re: Problems when passing messages to a source block
OK, it does work, as long as there is a message port defined and connected
in a flowgraph. I was trying too simple an example. You would do your
thread management in the start() and stop() functions.
"""
Embedded Python Blocks:
Each time this file is saved, GRC will instantiate the first class it finds
to get ports and parameters of your block. The arguments to __init__ will
be the parameters. All of them are required to have default values!
"""
import numpy as np
from gnuradio import gr
import pmt
class blk(gr.sync_block): # other base classes are basic_block,
decim_block, interp_block
"""Embedded Python Block example - a simple multiply const"""
def __init__(self): # only default arguments here
"""arguments to this function show up as parameters in GRC"""
gr.sync_block.__init__(
self,
name='Embedded Python Block', # will show up in GRC
in_sig=[],
out_sig=[]
)
self.message_port_register_out(pmt.intern("msgout"))
print('init')
def start(self):
print('start')
return True
def stop(self):
print('stop')
return True
On Mon, Nov 29, 2021 at 2:13 PM Jeff Long wrote:
> Issue submitted: https://github.com/gnuradio/gnuradio/issues/5358
>
> On Mon, Nov 29, 2021 at 1:58 PM Jeff Long wrote:
>
>> It does not seem that python blocks can override start() and stop(),
>> which they should be able to do. So, don't go too far down that path. I do
>> not see anywhere in the code where this is used or would have been caught.
>>
>> The embedded blocks are easier, be beware that GRC calls the init
>> function to learn about the block. Therefore, you don't want any action
>> taken as a result of a call to init, for instance spawning a thread and
>> starting to send messages. Embedded python block are sort of a toy that
>> turned out to be useful. In general, an OOT is a better idea, but an
>> embedded block can work if it's simple enough.
>>
>> Maybe someone else has figured this out. With just a quick look, I don't
>> see how a Message Strobe kind of block can be implemented in python without
>> start() and stop().
>>
>> Here's kind of a hack: make a python block with a message handler that
>> gets a periodic strobe from the existing Message Strobe block. In the
>> handler, send out the message that you would have sent in the thread.
>>
>
How to reset stream to vector block?
Hello, I'm working on a basic gnuradio flowgraph which is consist of a usrp source and a zmq pub sink. I am using usrp source with issue_stream_cmd in "STREAM_MODE_NUM_SAMPS_AND_MORE" mode. My goal is to request N number of samples from usrp source at specific times send data to ZMQ pub sink. Usrp source gives requested N number of samples in several packets but it is not suitable for my application. I need to send N samples to ZMQ as one pakcet. So, I decided to use a stream to vector block between usrp source and zmq pub sink, but there is a problem. In my application, I try to make usrp source stop immediately after starting the flowgraph so that it only sends data when I request. However, when flowgraph is started, usrp source starts streaming data until usrp source is stopped for a short time. So, if I put a stream to vector block between usrp source and zmq pub sink, some data from beginning of the flowgraph will be stored in stream to vector block. Therefore, I need to reset stream to vector block before I send a stream request to get requested data as one packet. There are two possible solutions: 1- Configuring usrp source such that it does not start streaming when the flowgraph is started. (making it stop has another problems, I will ask help for it in further e-mails.) 2- Resetting/flushing stream to vector block when flowgraph is running. I couldn't find any functions to reset or at least change vector size of stream to vector block (to make it 0 at the beginning and set to N when required). I tried setting stream to vector block to a new created stream to vector block while flowgraph is running but it didn't work. I tried locking the flowgraph, disconnecting stream to vector block and connecting a new stream to vector block and unlocking the flowgraph. When I unlock the flowgraph, usrp source starts streaming again and fills the new stream to vector block, so it didn't solve the problem. The only way that I can make it work is, (after stopping usrp soruce) disconnecting old block, creating a new block and connecting it while flowgraph is running without locking. It seems it is working this way but I don't think it is a good way to do it, so I am searching for better solutions. I don't have much experience with gnuradio, any suggestions would be helpful. I am using gnuradio version 3.8.3.1 with usrp E310 Thanks. Ali
Re: Problems when passing messages to a source block
Issue submitted: https://github.com/gnuradio/gnuradio/issues/5358 On Mon, Nov 29, 2021 at 1:58 PM Jeff Long wrote: > It does not seem that python blocks can override start() and stop(), > which they should be able to do. So, don't go too far down that path. I do > not see anywhere in the code where this is used or would have been caught. > > The embedded blocks are easier, be beware that GRC calls the init function > to learn about the block. Therefore, you don't want any action taken as a > result of a call to init, for instance spawning a thread and starting to > send messages. Embedded python block are sort of a toy that turned out to > be useful. In general, an OOT is a better idea, but an embedded block can > work if it's simple enough. > > Maybe someone else has figured this out. With just a quick look, I don't > see how a Message Strobe kind of block can be implemented in python without > start() and stop(). > > Here's kind of a hack: make a python block with a message handler that > gets a periodic strobe from the existing Message Strobe block. In the > handler, send out the message that you would have sent in the thread. >
Re: Calling blocks directly
To do this, you write a "mock" framework that calls the block init, then calls general_work() or work() with the proper parameters. I'd say you need to understand the C++ API for blocks pretty well to make this work. How much of the framework you need to implement will depend on which blocks you use. On Mon, Nov 29, 2021 at 1:28 PM Andra-Maria Ilies wrote: > Hello, > > > I am trying to write a full-program optimizer for GNURadio flow graphs in > C++. For this purpose, I need to call GNURadio blocks separately inside my > program. > > > I have 2 questions: > >1. How to directly feed a local vector input to a block? >2. How can I set a local array as the output array of the used block? > > I would like to mention that I want to do this directly, without using GNU > Radio specific functions such as connect(), because I will be using only > certain blocks, whose operation I find useful for my application. > > > Thank you in advance! > > Andra >
Re: Problems when passing messages to a source block
It does not seem that python blocks can override start() and stop(), which they should be able to do. So, don't go too far down that path. I do not see anywhere in the code where this is used or would have been caught. The embedded blocks are easier, be beware that GRC calls the init function to learn about the block. Therefore, you don't want any action taken as a result of a call to init, for instance spawning a thread and starting to send messages. Embedded python block are sort of a toy that turned out to be useful. In general, an OOT is a better idea, but an embedded block can work if it's simple enough. Maybe someone else has figured this out. With just a quick look, I don't see how a Message Strobe kind of block can be implemented in python without start() and stop(). Here's kind of a hack: make a python block with a message handler that gets a periodic strobe from the existing Message Strobe block. In the handler, send out the message that you would have sent in the thread.
Calling blocks directly
Hello, I am trying to write a full-program optimizer for GNURadio flow graphs in C++. For this purpose, I need to call GNURadio blocks separately inside my program. I have 2 questions: 1. How to directly feed a local vector input to a block? 2. How can I set a local array as the output array of the used block? I would like to mention that I want to do this directly, without using GNU Radio specific functions such as connect(), because I will be using only certain blocks, whose operation I find useful for my application. Thank you in advance! Andra
Re: Problems when passing messages to a source block
Minor correction - as is done in Message Strobe, you don't want the thread
to start running until start() is called. You can create the thread in
init() or start(). The Message Strobe creates its thread in start().
On Mon, Nov 29, 2021 at 11:07 AM Jeff Long wrote:
> The work() functions are for stream handling. You may have already read
>
> https://wiki.gnuradio.org/index.php/Message_Passing
>
> The approach here should be to create a separate thread in your init, and
> have that thread periodically public a message. There is a Message Strobe
> block that does this (in C++) and you could take a look at that code as an
> example.
>
> On Mon, Nov 29, 2021 at 10:06 AM Michelle wrote:
>
>> Good morning,
>>
>> I want to generate a source controlled by voltage. Basically, I send
>> messages to a source in order to change its amplitude. I have built a block
>> to generate messages and pass them to the source. To do so, I created an
>> "embedded python block " that generates and transmits a message every
>> second, here is the python code of my block:
>>
>> from gnuradio import gr, blocks
>> import pmt
>> import numpy
>> import time
>>
>> #The block receives input data (the amplitude of a signal) then generates
>> a message to be passed to a constant source so that the latter modifies its
>> amplitude"
>>
>> class message_generator(gr.sync_block):
>> def __init__(self):
>> gr.sync_block.__init__(
>> self,
>> name="message generator",
>> in_sig=[numpy.float32], #amplitude that the signal must have
>> out_sig=None
>> )
>> self.message_port_register_out(pmt.intern('out_port'))
>>
>>
>> def work(self, input_items, output_items):
>>self.msg_port_pub(pmt.intern('out_port'),
>> pmt.cons(pmt.intern("ampl"), pmt.from_double(input_items[0][0])))
>>time.sleep(1)
>>return 1
>>
>>
>> when I execute my flowgraph in gnuradio I have the error :
>> self.msg_port_pub(pmt.intern('out_port'), pmt.cons(pmt.intern("ampl"),
>> pmt.from_double(input_items[0][0])))
>> AttributeError: 'message_generator' object has no attribute
>> 'msg_port_pub' . And I can't understand why if in the
>> qa_python_message_passing.py
>>
>> (below ) the function message_port_pub is called the same way as I do in
>> mine.
>>
>> class message_generator(gr.sync_block):
>> def __init__(self, msg_interval = 10):
>> gr.sync_block.__init__(
>> self,
>> name="message generator",
>> in_sig=[numpy.float32], #amplitude that the signal must have
>> out_sig=None
>> )
>> self.msg_list = []
>> #self.message_port_register_in(pmt.intern('in_port'))
>> self.message_port_register_out(pmt.intern('out_port'))
>> self.msg_interval = msg_interval
>> self.msg_ctr = 0
>>
>>
>> def work(self, input_items, output_items):
>>
>> inLen = len(input_items[0])
>>
>> # Create a new PMT for each input value and put it in the message
>> list
>> self.msg_list.append(pmt.from_double(input_items[0][0]))
>>
>> while self.msg_ctr < len(self.msg_list) and \
>> (self.msg_ctr * self.msg_interval) < \
>> (self.nitems_read(0) + inLen):
>> self.message_port_pub(pmt.intern('out_port'),
>>
>> pmt.cons(pmt.intern("ampl"),self.msg_list[self.msg_ctr]))
>> self.msg_ctr += 1
>> return inLen
>>
>>
>> PLease can you explain to me what is wrong on my code? I even tried to
>> put an attribute "msg_port_pub" when declaring the class but I still have
>> the same error.
>>
>> from gnuradio import gr, blocks
>> import pmt
>> import numpy
>> import time
>>
>> class message_generator(gr.sync_block):
>> def __init__(self):
>> gr.sync_block.__init__(
>> self,
>> name="message generator",
>> in_sig=[numpy.float32], #amplitude that the signal must have
>> out_sig=None
>> )
>> d_port= self.message_port_register_out(pmt.intern('out_port'))
>> self.msg_port_pub(d_port, self.buildMessage)
>>
>> def buildMessage(self, data):
>>msg = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
>>return msg
>>
>>
>> def work(self, input_items, output_items):
>>messageToSend = builMessage(input_items=[0][0])
>>self.msg_port_pub(d_port, messageToSend)
>>time.sleep(1)
>>return 1
>>
>>
>> You can find attached my flowgraph and the resulting python code.
>>
>> Thank you in advance and have a good day.
>>
>>
>>
Re: Problems when passing messages to a source block
The work() functions are for stream handling. You may have already read
https://wiki.gnuradio.org/index.php/Message_Passing
The approach here should be to create a separate thread in your init, and
have that thread periodically public a message. There is a Message Strobe
block that does this (in C++) and you could take a look at that code as an
example.
On Mon, Nov 29, 2021 at 10:06 AM Michelle wrote:
> Good morning,
>
> I want to generate a source controlled by voltage. Basically, I send
> messages to a source in order to change its amplitude. I have built a block
> to generate messages and pass them to the source. To do so, I created an
> "embedded python block " that generates and transmits a message every
> second, here is the python code of my block:
>
> from gnuradio import gr, blocks
> import pmt
> import numpy
> import time
>
> #The block receives input data (the amplitude of a signal) then generates
> a message to be passed to a constant source so that the latter modifies its
> amplitude"
>
> class message_generator(gr.sync_block):
> def __init__(self):
> gr.sync_block.__init__(
> self,
> name="message generator",
> in_sig=[numpy.float32], #amplitude that the signal must have
> out_sig=None
> )
> self.message_port_register_out(pmt.intern('out_port'))
>
>
> def work(self, input_items, output_items):
>self.msg_port_pub(pmt.intern('out_port'),
> pmt.cons(pmt.intern("ampl"), pmt.from_double(input_items[0][0])))
>time.sleep(1)
>return 1
>
>
> when I execute my flowgraph in gnuradio I have the error :
> self.msg_port_pub(pmt.intern('out_port'), pmt.cons(pmt.intern("ampl"),
> pmt.from_double(input_items[0][0])))
> AttributeError: 'message_generator' object has no attribute 'msg_port_pub'
> . And I can't understand why if in the qa_python_message_passing.py
>
> (below ) the function message_port_pub is called the same way as I do in
> mine.
>
> class message_generator(gr.sync_block):
> def __init__(self, msg_interval = 10):
> gr.sync_block.__init__(
> self,
> name="message generator",
> in_sig=[numpy.float32], #amplitude that the signal must have
> out_sig=None
> )
> self.msg_list = []
> #self.message_port_register_in(pmt.intern('in_port'))
> self.message_port_register_out(pmt.intern('out_port'))
> self.msg_interval = msg_interval
> self.msg_ctr = 0
>
>
> def work(self, input_items, output_items):
>
> inLen = len(input_items[0])
>
> # Create a new PMT for each input value and put it in the message
> list
> self.msg_list.append(pmt.from_double(input_items[0][0]))
>
> while self.msg_ctr < len(self.msg_list) and \
> (self.msg_ctr * self.msg_interval) < \
> (self.nitems_read(0) + inLen):
> self.message_port_pub(pmt.intern('out_port'),
>
> pmt.cons(pmt.intern("ampl"),self.msg_list[self.msg_ctr]))
> self.msg_ctr += 1
> return inLen
>
>
> PLease can you explain to me what is wrong on my code? I even tried to put
> an attribute "msg_port_pub" when declaring the class but I still have the
> same error.
>
> from gnuradio import gr, blocks
> import pmt
> import numpy
> import time
>
> class message_generator(gr.sync_block):
> def __init__(self):
> gr.sync_block.__init__(
> self,
> name="message generator",
> in_sig=[numpy.float32], #amplitude that the signal must have
> out_sig=None
> )
> d_port= self.message_port_register_out(pmt.intern('out_port'))
> self.msg_port_pub(d_port, self.buildMessage)
>
> def buildMessage(self, data):
>msg = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
>return msg
>
>
> def work(self, input_items, output_items):
>messageToSend = builMessage(input_items=[0][0])
>self.msg_port_pub(d_port, messageToSend)
>time.sleep(1)
>return 1
>
>
> You can find attached my flowgraph and the resulting python code.
>
> Thank you in advance and have a good day.
>
>
>
Problems when passing messages to a source block
Good morning,
I want to generate a source controlled by voltage. Basically, I send
messages to a source in order to change its amplitude. I have built a
block to generate messages and pass them to the source. To do so, I
created an "embedded python block " that generates and transmits a
message every second, here is the python code of my block:
from gnuradio import gr, blocks
import pmt
import numpy
import time
#The block receives input data (the amplitude of a signal) then
generates a message to be passed to a constant source so that the latter
modifies its amplitude"
class message_generator(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=[numpy.float32], #amplitude that the signal must have
out_sig=None
)
self.message_port_register_out(pmt.intern('out_port'))
def work(self, input_items, output_items):
self.msg_port_pub(pmt.intern('out_port'),
pmt.cons(pmt.intern("ampl"), pmt.from_double(input_items[0][0])))
time.sleep(1)
return 1
when I execute my flowgraph in gnuradio I have the error :
self.msg_port_pub(pmt.intern('out_port'), pmt.cons(pmt.intern("ampl"),
pmt.from_double(input_items[0][0])))
AttributeError: 'message_generator' object has no attribute
'msg_port_pub' . And I can't understand why if in the
qa_python_message_passing.py
(below ) the function message_port_pub is called the same way as I do in
mine.
class message_generator(gr.sync_block):
def __init__(self, msg_interval = 10):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=[numpy.float32], #amplitude that the signal must have
out_sig=None
)
self.msg_list = []
#self.message_port_register_in(pmt.intern('in_port'))
self.message_port_register_out(pmt.intern('out_port'))
self.msg_interval = msg_interval
self.msg_ctr = 0
def work(self, input_items, output_items):
inLen = len(input_items[0])
# Create a new PMT for each input value and put it in the
message list
self.msg_list.append(pmt.from_double(input_items[0][0]))
while self.msg_ctr < len(self.msg_list) and \
(self.msg_ctr * self.msg_interval) < \
(self.nitems_read(0) + inLen):
self.message_port_pub(pmt.intern('out_port'),
pmt.cons(pmt.intern("ampl"),self.msg_list[self.msg_ctr]))
self.msg_ctr += 1
return inLen
PLease can you explain to me what is wrong on my code? I even tried to
put an attribute "msg_port_pub" when declaring the class but I still
have the same error.
from gnuradio import gr, blocks
import pmt
import numpy
import time
class message_generator(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name="message generator",
in_sig=[numpy.float32], #amplitude that the signal must have
out_sig=None
)
d_port= self.message_port_register_out(pmt.intern('out_port'))
self.msg_port_pub(d_port, self.buildMessage)
def buildMessage(self, data):
msg = pmt.cons(pmt.intern("ampl"), pmt.from_double(data))
return msg
def work(self, input_items, output_items):
messageToSend = builMessage(input_items=[0][0])
self.msg_port_pub(d_port, messageToSend)
time.sleep(1)
return 1
You can find attached my flowgraph and the resulting python code.
Thank you in advance and have a good day.
xx.grc
Description: application/gnuradio-grc
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# SPDX-License-Identifier: GPL-3.0
#
# GNU Radio Python Flow Graph
# Title: xx
# Author: me
# GNU Radio version: 3.8.2.0
from distutils.version import StrictVersion
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print("Warning: failed to XInitThreads()")
from PyQt5 import Qt
from gnuradio import qtgui
from gnuradio.filter import firdes
import sip
from gnuradio import analog
from gnuradio import blocks
from gnuradio import gr
import sys
import signal
from argparse import ArgumentParser
from gnuradio.eng_arg import eng_float, intx
from gnuradio import eng_notation
import epy_block_1
from gnuradio import qtgui
class xx(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "xx")
Qt.QWidget.__init__(self)
self.setWindowTitle("xx")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
Error with two versions of GNU Radio: 3.7.13.4 and 3.8.0.0
Hello I'm Isaac. I've installed GNU Radio 3.8.0.0, my second version of GNU Radio for one pc, following the steps of this website: https://kb.ettus.com/Building_and_Installing_UHD_and_GNU_Radio_to_a_Custom_Prefix I could run GRC, but some errors appear regarding qtgui: Warning: restarting the docstring loader (crashed while loading 'qtgui_bercurve_sink') Warning: restarting the docstring loader (crashed while loading 'qtgui_const_sink_x') Warning: restarting the docstring loader (crashed while loading 'qtgui_edit_box_msg') Warning: restarting the docstring loader (crashed while loading 'qtgui_freq_sink_x') Warning: restarting the docstring loader (crashed while loading 'qtgui_histogram_sink_x') Warning: docstring loader crashed too often My GRC also closes immediately if I try to open any QT block. How could I solve this error? Is it possible to solve this mistake without eliminating my old version of GR (3.7.13.4)? Please any help will be appreciated. Regards Isaac T.
?????? Multithreading error?
Hi, Thank you very much for your detailed answer. Although I have been in contact with GNURadio for a while, I have not used the PMT message port. I will take this opportunity to learn how to use the message port. Thanks again Sincerely, linge93 ---- ??: "Marcus M??ller"
Re: Multithreading error?
Using matplotlib from a work method is simply a bad idea. Don't do it! (I think we spoke
about that in chat, didn't we?)
I'd recommend instead:
0. Add a "QT GUI Graphic Item" to your flow graph in GRC
1. Add a message output port to your block, call it e.g. "image_data"
2. in your work() method, calculate the image you want to display (i.e. your
re_img[0] )
3. send a PMT message that's a cons( cons(width, height),
u8vec(re_img[0].tolist())
4. Implement a Python block that has a message output port "image_file", and a message
input port "image_data", with a message handler, which
1. takes the data from the PMT
2. uses the `cv2` python library to convert the data to an image,
3. uses the `tempfile` library to write that to temporary file
4. send that filename to the message output port
5. connect your signal processing block's "image_data" output to your picture-writing
block's "image_data" input
6. connect your picture-writing block's "image_file" output to QT GUI Graphic Item's
"filename" input
Best regards,
Marcus
On 29.11.21 10:52, 能书能言 wrote:
Hi,
I designed a Python OOT sink block. The purpose of this block is to get the input
characters and store it in a variable. I can run a tensorflow model through this variable
to restore it to the original image. My work function is as follows:
def work(self, input_items, output_items):
in0 = input_items[0]
n = len(in0)
i = 0
while(i rv_img = np.concatenate([np.reshape(np.real(rx), [1, -1]),
np.reshape(np.imag(rx), [1, -1])], axis=0)
rv_img = np.reshape(rv_img, self.inter_shape)
re_img = self.de_model.predict(rv_img)
mse = np.mean(np.square(re_img-self.img_array))
print(mse)
plt.subplot(111)
plt.imshow(re_img[0]/255)
plt.show()
return len(input_items[0])
But when I clicked to run the flow graph, the following error occurred:
Exception ignored in:
Traceback (most recent call last):
File "/usr/lib/python3.8/tkinter/__init__.py", line 4017, in __del__
self.tk.call('image','delete', self.name)
RuntimeError: main thread is not in main loop
Tcl_AsyncDelete: async handler deleted by the wrong thread
This seems to be a problem with matplotlib drawing. In fact, the final result is that I
can restore the picture I want. In other words, the basic functions can be realized now,
but the error prompted by the terminal does not look good. , I want to make it perfect, if
anyone has some good suggestions I would not be very grateful, thank you!
Sincerely,
linge93
smime.p7s
Description: S/MIME Cryptographic Signature
Multithreading error?
Hi, I designed a Python OOT sink block. The purpose of this block is to get the input characters and store it in a variable. I can run a tensorflow model through this variable to restore it to the original image. My work function is as follows: def work(self, input_items, output_items): in0 = input_items[0] n = len(in0) i = 0 while(i
Open PhD positions at ANT, Uni Bremen
Hi all, we have quite a few open positions for PhD candidates at our institute. If you're interested, I pasted the description in this email. You can find the description here: https://www.ant.uni-bremen.de/en/int_jobs/ Cheers Johannes As a key partner in various collaborative research projects, the Department of Communications Engineering (headed by Prof. Dr.-Ing. Armin Dekorsy) of the University of Bremen has been researching innovative concepts, methods and technologies for future communication systems with a focus on baseband signal processing. To complement our research teams, we are looking for 13 PhD-candidates and at least 2 postdoctoral researchers in the following areas: - 6G communication system - Satellite communications - Swarm exploration on Mars - Quantum communications. Potential research topics include, but are not limited to: - Information transmission and interference management in 6G network concepts - 6G network concepts and architectures: terrestrial-orbital (3D) networks, organic networks, OpenRAN, dynamic subnetworks - Source and channel coding (e.g. Information Bottleneck Method) - Event-based sampling, Event-based communication - Semantic communication - Graph-based, distributed signal processing and compressive sensing - Machine learning methods, Bayesian learning methods - mmWave (26GHz) communication and localization The candidates are expected to have skills that cover one or more of the following areas: - Communications engineering (baseband, resource management) - Signal processing and signal theory - Coding and information theory - Network information theory - Machine learning, stochastic inference techniques. We are looking for candidates carrying out at least one of the following activities - Fundamental, theoretical-oriented research - Software implementation of innovative technologies, e.g. in an 6G testbed. If you have a very good M.Sc. degree in electrical engineering/information technology, computer engineering or applied mathematics and are interested in conducting independent research with your ideas and approaches as a member of one of our research teams, we look forward to receiving your unsolicited application. The possibility of a doctorate is given for all positions. Please send your application (brief cover letter, CV. transcripts, certificates, list of pub if applicable) to applicati...@ant.uni-bremen.de
