hwo to convert 3.8 GRC to 3.7

[james jordan]

hi,
i have an grc that making using gnuradio 3.8 but my gnuradio is 3.7. install a 
new version seems difficult for me. so is there any way to convert the grc to 
3.7

Re: hwo to convert 3.8 GRC to 3.7

[Marcus Müller]

Hi james,

That's not possible without manually rebuilding it, if all blocks used
are even available in 3.7.

3.7 is largely a legacy system, I'd strongly recommend against porting
something *back* to it.

It's usually not that hard to get a modern GNU Radio, so honestly, let's
rather work on installing GNU Radio 3.8.
Why is that not possible for you?

Best regards,
Marcus

On 13.01.21 11:30, james jordan wrote:
> hi,
> i have an grc that making using gnuradio 3.8 but my gnuradio is 3.7.
> install a new version seems difficult for me. so is there any way to
> convert the grc to 3.7
> 
> 
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: hwo to convert 3.8 GRC to 3.7

[Sylvain Munaut]

> It's usually not that hard to get a modern GNU Radio, so honestly, let's
> rather work on installing GNU Radio 3.8.

I'd suggest 3.9 directly.

Cheers,

   Sylvain

Re: hwo to convert 3.8 GRC to 3.7

[Marcus Müller]

Gotcha! I'm on it; still on my dayjob's lunch break, though.

On 13.01.21 13:36, Sylvain Munaut wrote:
>> It's usually not that hard to get a modern GNU Radio, so honestly, let's
>> rather work on installing GNU Radio 3.8.
> 
> I'd suggest 3.9 directly.
> 
> Cheers,
> 
>Sylvain
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Vector Source and QT GUI Time Sink causes performance drop

[Marcus Müller]

Well, since it works for every other GNU Radio user:
possibly your graphics driver is buggy, or Qt. Hard to tell!

On 11.01.21 16:53, Mariusz Pluciński wrote:
> Hi,
> 
> Thanks for the hint, I didn't know about this method of profiling :). I
> did as you requested and it seems that it spends quite a lot of time in
> Qt, namely in *gray_render_line* and *gray_render_scanline* functions.
> If my understanding is correct, this time is spent in Qt itself, not in
> the underlying graphics stack. Which would mean that either GNU Radio
> generates too many rendering requests or this version of Qt is buggy.
> What do you think?
> 
> Full output:
> 
> +   33,04%    32,32%  python3          libQt5Gui.so.5                  
>                  [.] gray_render_line
> +   23,39%    22,70%  python3          libQt5Gui.so.5                  
>                  [.] gray_render_scanline
> +   11,10%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] secondary_startup_64
> +   11,10%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] cpu_startup_entry
> +   11,08%     0,02%  swapper          [kernel.kallsyms]                
>                 [k] do_idle
> +   10,59%     0,01%  swapper          [kernel.kallsyms]                
>                 [k] call_cpuidle
> +   10,58%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] cpuidle_enter
> +   10,56%     0,04%  swapper          [kernel.kallsyms]                
>                 [k] cpuidle_enter_state
> +   10,08%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] start_secondary
> +    6,50%     0,02%  swapper          [kernel.kallsyms]                
>                 [k] acpi_idle_enter
> +    6,47%     6,20%  swapper          [kernel.kallsyms]                
>                 [k] acpi_processor_ffh_cstate_enter
> +    6,46%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_idle_do_entry
> +    4,26%     0,00%  python3          [unknown]                        
>                 [k] 0x0004
> +    4,15%     0,35%  python3          libc-2.31.so
>                                       [.] __sched_yield
> +    4,04%     0,01%  swapper          [kernel.kallsyms]                
>                 [k] acpi_idle_enter_bm
> +    3,57%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] ret_from_intr
> +    3,57%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] do_IRQ
> +    3,56%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] handle_fasteoi_irq
> +    3,56%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] handle_irq_event
> +    3,56%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] handle_irq_event_percpu
> +    3,48%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] __handle_irq_event_percpu
> +    3,37%     0,14%  python3          [kernel.kallsyms]                
>                 [k] entry_SYSCALL_64_after_hwframe
> +    3,18%     0,08%  python3          [kernel.kallsyms]                
>                 [k] do_syscall_64
> +    2,87%     0,06%  python3          [kernel.kallsyms]                
>                 [k] __x64_sys_sched_yield
> +    2,65%     0,08%  python3          [kernel.kallsyms]                
>                 [k] do_sched_yield
> +    2,54%     0,07%  python3          [kernel.kallsyms]                
>                 [k] schedule
> +    2,30%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_irq
> +    2,29%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_ev_sci_xrupt_handler
> +    2,27%     0,42%  python3          [kernel.kallsyms]                
>                 [k] __sched_text_start
> +    2,26%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_ev_gpe_detect
> +    2,23%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_ev_detect_gpe
> +    2,01%     0,04%  WebExtensions    [unknown]                        
>                 [.] 
> +    1,96%     0,01%  swapper          [kernel.kallsyms]                
>                 [k] acpi_hw_read
> +    1,94%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_hw_read_port
> +    1,93%     1,93%  swapper          [kernel.kallsyms]                
>                 [k] acpi_os_read_port
> +    1,50%     0,43%  python3          [kernel.kallsyms]                
>                 [k] pick_next_task_fair
> +    1,10%     0,00%  WebExtensions    [unknown]                        
>                 [.] 0xf8894804751efe83
> +    1,10%     0,00%  WebExtensions    libxul.so                        
> 

Re: Vector Source and QT GUI Time Sink causes performance drop

[Marcus Müller]

by the way, there's no GNU Radio at all in this profile – are you sure
you ran exactly the `perf record -ag python path/to/..` as recommended?

On 11.01.21 16:53, Mariusz Pluciński wrote:
> Hi,
> 
> Thanks for the hint, I didn't know about this method of profiling :). I
> did as you requested and it seems that it spends quite a lot of time in
> Qt, namely in *gray_render_line* and *gray_render_scanline* functions.
> If my understanding is correct, this time is spent in Qt itself, not in
> the underlying graphics stack. Which would mean that either GNU Radio
> generates too many rendering requests or this version of Qt is buggy.
> What do you think?
> 
> Full output:
> 
> +   33,04%    32,32%  python3          libQt5Gui.so.5                  
>                  [.] gray_render_line
> +   23,39%    22,70%  python3          libQt5Gui.so.5                  
>                  [.] gray_render_scanline
> +   11,10%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] secondary_startup_64
> +   11,10%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] cpu_startup_entry
> +   11,08%     0,02%  swapper          [kernel.kallsyms]                
>                 [k] do_idle
> +   10,59%     0,01%  swapper          [kernel.kallsyms]                
>                 [k] call_cpuidle
> +   10,58%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] cpuidle_enter
> +   10,56%     0,04%  swapper          [kernel.kallsyms]                
>                 [k] cpuidle_enter_state
> +   10,08%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] start_secondary
> +    6,50%     0,02%  swapper          [kernel.kallsyms]                
>                 [k] acpi_idle_enter
> +    6,47%     6,20%  swapper          [kernel.kallsyms]                
>                 [k] acpi_processor_ffh_cstate_enter
> +    6,46%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_idle_do_entry
> +    4,26%     0,00%  python3          [unknown]                        
>                 [k] 0x0004
> +    4,15%     0,35%  python3          libc-2.31.so
>                                       [.] __sched_yield
> +    4,04%     0,01%  swapper          [kernel.kallsyms]                
>                 [k] acpi_idle_enter_bm
> +    3,57%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] ret_from_intr
> +    3,57%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] do_IRQ
> +    3,56%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] handle_fasteoi_irq
> +    3,56%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] handle_irq_event
> +    3,56%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] handle_irq_event_percpu
> +    3,48%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] __handle_irq_event_percpu
> +    3,37%     0,14%  python3          [kernel.kallsyms]                
>                 [k] entry_SYSCALL_64_after_hwframe
> +    3,18%     0,08%  python3          [kernel.kallsyms]                
>                 [k] do_syscall_64
> +    2,87%     0,06%  python3          [kernel.kallsyms]                
>                 [k] __x64_sys_sched_yield
> +    2,65%     0,08%  python3          [kernel.kallsyms]                
>                 [k] do_sched_yield
> +    2,54%     0,07%  python3          [kernel.kallsyms]                
>                 [k] schedule
> +    2,30%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_irq
> +    2,29%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_ev_sci_xrupt_handler
> +    2,27%     0,42%  python3          [kernel.kallsyms]                
>                 [k] __sched_text_start
> +    2,26%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_ev_gpe_detect
> +    2,23%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_ev_detect_gpe
> +    2,01%     0,04%  WebExtensions    [unknown]                        
>                 [.] 
> +    1,96%     0,01%  swapper          [kernel.kallsyms]                
>                 [k] acpi_hw_read
> +    1,94%     0,00%  swapper          [kernel.kallsyms]                
>                 [k] acpi_hw_read_port
> +    1,93%     1,93%  swapper          [kernel.kallsyms]                
>                 [k] acpi_os_read_port
> +    1,50%     0,43%  python3          [kernel.kallsyms]                
>                 [k] pick_next_task_fair
> +    1,10%     0,00%  WebExtensions    [unknown]                        
>                 [.] 0xf8894804751efe83
> +    1,10%     0,00%  WebExtensions    libxul.

Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/12/2021 02:51 PM, Lamar Owen wrote:




I'm trying to debug and patch the UHD stack for USRP1 with DBS-RX 
daughterboard; it just quit working, and while I've reported to the 
UHD list no action has been taken to fix the regression.
I was able to reproduce the regression issue with DBS-RX on my own 
ancient USRP1 hardware, and it has been reported.  But I don't know
  how much engineering bandwidth will be devoted to fixing it.  The 
regression goes back a few UHD release versions--I didn't go all the way
  "back in time" to figure out where it happened, but it isn't just 
with the latest release :(

Help with keyboard input

[Barry Duggan]

I know this is not a GNU Radio problem directly, but I hope maybe 
someone has some insight into this.


I have a Lenovo ThinkCentre M75s with a AMD® Ryzen 7 PRO 3700 Processor.
I am running Ubuntu 20.04  I am having difficulties with keyboard 
devices. Only a wired keyboard works reliably. Lenovo support has been 
no help at all.


If I use a USB keyboard, it will work for a while (5-10 minutes) and 
then be locked out.


If I try to use a Bluetooth keyboard, it may or may not be discovered. 
Even if it is, after a few days of leaving it on, or after a reboot, it 
will be disconnected and will not reconnect.


I don't know if the problem is with the USB driver, the Bluetooth 
driver, or the Lenovo hardware.


Any help would be appreciated greatly!

--
Barry Duggan KV4FV
https://github.com/duggabe

Re: Help with keyboard input

[Jeff Long]

See if it's this: https://hamwaves.com/usb.autosuspend/en/

On Wed, Jan 13, 2021 at 2:12 PM Barry Duggan  wrote:

> I know this is not a GNU Radio problem directly, but I hope maybe
> someone has some insight into this.
>
> I have a Lenovo ThinkCentre M75s with a AMD® Ryzen 7 PRO 3700 Processor.
> I am running Ubuntu 20.04  I am having difficulties with keyboard
> devices. Only a wired keyboard works reliably. Lenovo support has been
> no help at all.
>
> If I use a USB keyboard, it will work for a while (5-10 minutes) and
> then be locked out.
>
> If I try to use a Bluetooth keyboard, it may or may not be discovered.
> Even if it is, after a few days of leaving it on, or after a reboot, it
> will be disconnected and will not reconnect.
>
> I don't know if the problem is with the USB driver, the Bluetooth
> driver, or the Lenovo hardware.
>
> Any help would be appreciated greatly!
>
> --
> Barry Duggan KV4FV
> https://github.com/duggabe
>
>

Re: Help with keyboard input

[Fabian Schwartau]

If you can reproduce a failing wired keyboard, check what
/var/log/syslog says when it turns off. Use
tail -f /var/log/syslog
to monitor the output continously. There should be some note on what is
going on. A look in the xorg/wayland logs may also help.

Am 13.01.21 um 20:03 schrieb Barry Duggan:
> I know this is not a GNU Radio problem directly, but I hope maybe
> someone has some insight into this.
> 
> I have a Lenovo ThinkCentre M75s with a AMD® Ryzen 7 PRO 3700 Processor.
> I am running Ubuntu 20.04  I am having difficulties with keyboard
> devices. Only a wired keyboard works reliably. Lenovo support has been
> no help at all.
> 
> If I use a USB keyboard, it will work for a while (5-10 minutes) and
> then be locked out.
> 
> If I try to use a Bluetooth keyboard, it may or may not be discovered.
> Even if it is, after a few days of leaving it on, or after a reboot, it
> will be disconnected and will not reconnect.
> 
> I don't know if the problem is with the USB driver, the Bluetooth
> driver, or the Lenovo hardware.
> 
> Any help would be appreciated greatly!
> 

Re: Help with keyboard input

[Doug McGarrett]

On 1/13/21 3:09 PM, Fabian Schwartau wrote:

If you can reproduce a failing wired keyboard, check what
/var/log/syslog says when it turns off. Use
tail -f /var/log/syslog
to monitor the output continously. There should be some note on what is
going on. A look in the xorg/wayland logs may also help.

Am 13.01.21 um 20:03 schrieb Barry Duggan:

I know this is not a GNU Radio problem directly, but I hope maybe
someone has some insight into this.

I have a Lenovo ThinkCentre M75s with a AMD® Ryzen 7 PRO 3700 Processor.
I am running Ubuntu 20.04  I am having difficulties with keyboard
devices. Only a wired keyboard works reliably. Lenovo support has been
no help at all.

If I use a USB keyboard, it will work for a while (5-10 minutes) and
then be locked out.

If I try to use a Bluetooth keyboard, it may or may not be discovered.
Even if it is, after a few days of leaving it on, or after a reboot, it
will be disconnected and will not reconnect.

I don't know if the problem is with the USB driver, the Bluetooth
driver, or the Lenovo hardware.

Any help would be appreciated greatly!



You are looking for a wireless connection in either case. The problem 
may not be in
your hardware. It is possible that there is an intermittent interference 
condition in
your neighborhood. This could be caused by arcing power lines, or 
perhaps some
kind of machine being used intermittently in the area. Perhaps you 
should get an

extension cable so you can always use a wired connection.
--doug, retired RF engineer

3.9 Setup for OOT development

[Gavin Jacobs]

I am planning to update an OOT module I wrote 4 years ago. I setup a laptop 
with a fresh install of Ubuntu 20.04 to use for development. I installed GNU 
Radio 3.8, but then I decided to go with 3.9, so I removed 3.8, and installed 
3.9 from the PPA. Then I ran
modtool newmod streamx ...
cd streamx
modtool add ...
modtool  bind ...

and then tried
mkdir build
cd build
cmake ../

I didn't have cmake, so I installed that, and then doxygen, and then some 
others. Still getting errors so I installed ALL the dependencies for building 
GNU Radio as described here 
https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29.

I'm still getting the following errors from cmake
<...>
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
<...>
-- Python checking for pygccxml - not found
<...>
CMake Error in lib/CMakeLists.txt:
  Imported target "gnuradio::gnuradio-runtime" includes non-existent path
"/include"
  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

So, do I need mpir and pygccxml? If yes, where to find them and how to install?

How do I investigate the missing /include? I can see the include directory in 
my new streamx module, it's exactly where modtool put it.


Thanks,
Gavin


UbuntuInstall - GNU 
Radio
Building GNU Radio on Ubuntu Linux []. GNU Radio works well on all Ubuntu 
versions from 10.04 upward. It is also possible to install GNU Radio on older 
releases of Ubuntu (see #Building_GNU_Radio_on_Legacy_Ubuntu).However, we may 
not be able to provide sufficient support for legacy OS.
wiki.gnuradio.org



InstallingGR - GNU Radio
>From Binaries []. The recommended way to install GNU Radio on most platforms 
>is using already available binary packages (see Ubuntu PPA Installation).For 
>some platforms there are no binaries provided by available package managers or 
>the GNU Radio project.
wiki.gnuradio.org

Problem initializing parameters in Gnuradio Python Block?

[George Edwards]

Hello,

I am using a Gnuradio Python Block in my GRC signal processing and am
having problems initializing my parameters. My system has a number of
vector parameters to be initialized at startup. I will provide the gist of
my goal in a scaled down version of my work.
1. In the def __init__(self, start = True)  method, "start" is the
parameter that will be used in the program to run the initialization
process and is set as follows:
 self.start = start
2. In the work(self, input_items, output_items)  method, I have the
following at the start of the method:
 if self.start == True:
v = self.my_init()# go initialize all vectors

 output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2]  #computation
using v
 # with 3-inputs to the
block

3. In the my_init(self) method I have:
 self.start = False# set start to False
 v = np.array([1., 2., 3.])  #hypothetical to make this simple
 return v

When I run the GRC model, it tells me that "v" is referenced before
assignment. I am confused because I thought that the method my_init() would
have been called before the computation and would return the values for
"v". On the other hand if I do the assignment in the work(...) method as  v
= np.array([1., 2., 3.]), it works perfectly.
Question: Why was the my_init() method not called properly to get  the
values for the numpy array v?

Thanks for the help!

Regards,
George

Re: 3.9 Setup for OOT development

[Cinaed Simson]

Hi Gavin - you can probably ignore the first error - there are 2 
possible entries for multiple precision libraries.


And I believe you need pygccxml for OOT development in  3.9

Try

  apt install python3-pygccxml

you can always uninstall it.

Also it appears the you may be trying to use an old nonexistent path in 
lib/CMakeLists.txtfile?


-- Cinaed

On 1/13/21 12:32 PM, Gavin Jacobs wrote:

CMake Error in lib/CMakeLists.txt:
  Imported target "gnuradio::gnuradio-runtime" includes non-existent path
    "/include"
  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

Re: Problem initializing parameters in Gnuradio Python Block?

[Jeff Long]

'v' is a local variable in work(). It is probably crashing on the second
call, where my_init() is not called, and thus there is no 'v'.

On Wed, Jan 13, 2021 at 7:38 PM George Edwards 
wrote:

> Hello,
>
> I am using a Gnuradio Python Block in my GRC signal processing and am
> having problems initializing my parameters. My system has a number of
> vector parameters to be initialized at startup. I will provide the gist of
> my goal in a scaled down version of my work.
> 1. In the def __init__(self, start = True)  method, "start" is the
> parameter that will be used in the program to run the initialization
> process and is set as follows:
>  self.start = start
> 2. In the work(self, input_items, output_items)  method, I have the
> following at the start of the method:
>  if self.start == True:
> v = self.my_init()# go initialize all vectors
>
>  output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2]  #computation
> using v
>  # with 3-inputs to
> the block
>
> 3. In the my_init(self) method I have:
>  self.start = False# set start to False
>  v = np.array([1., 2., 3.])  #hypothetical to make this simple
>  return v
>
> When I run the GRC model, it tells me that "v" is referenced before
> assignment. I am confused because I thought that the method my_init() would
> have been called before the computation and would return the values for
> "v". On the other hand if I do the assignment in the work(...) method as  v
> = np.array([1., 2., 3.]), it works perfectly.
> Question: Why was the my_init() method not called properly to get  the
> values for the numpy array v?
>
> Thanks for the help!
>
> Regards,
> George
>

Re: Problem initializing parameters in Gnuradio Python Block?

[George Edwards]

Hi Jeff,

Thanks for your answer. You are right, it crashes on the second call.

So how do I write the program to initialize a bunch of vectors in a "method
strictly for initialization" when it first starts running? If this cannot
be done, then I guess the only solution is to initialize them in the work()
method even though it would make the work() method bulky?

Thanks again for your help.

Regards,
George

On Wed, Jan 13, 2021 at 8:12 PM Jeff Long  wrote:

> 'v' is a local variable in work(). It is probably crashing on the second
> call, where my_init() is not called, and thus there is no 'v'.
>
> On Wed, Jan 13, 2021 at 7:38 PM George Edwards 
> wrote:
>
>> Hello,
>>
>> I am using a Gnuradio Python Block in my GRC signal processing and am
>> having problems initializing my parameters. My system has a number of
>> vector parameters to be initialized at startup. I will provide the gist of
>> my goal in a scaled down version of my work.
>> 1. In the def __init__(self, start = True)  method, "start" is the
>> parameter that will be used in the program to run the initialization
>> process and is set as follows:
>>  self.start = start
>> 2. In the work(self, input_items, output_items)  method, I have the
>> following at the start of the method:
>>  if self.start == True:
>> v = self.my_init()# go initialize all vectors
>>
>>  output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2]
>> #computation using v
>>  # with 3-inputs to
>> the block
>>
>> 3. In the my_init(self) method I have:
>>  self.start = False# set start to False
>>  v = np.array([1., 2., 3.])  #hypothetical to make this simple
>>  return v
>>
>> When I run the GRC model, it tells me that "v" is referenced before
>> assignment. I am confused because I thought that the method my_init() would
>> have been called before the computation and would return the values for
>> "v". On the other hand if I do the assignment in the work(...) method as  v
>> = np.array([1., 2., 3.]), it works perfectly.
>> Question: Why was the my_init() method not called properly to get  the
>> values for the numpy array v?
>>
>> Thanks for the help!
>>
>> Regards,
>> George
>>
>