Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

And remember to run volk_profile

On Thu, Dec 17, 2020, 08:03 Albin Stigö  wrote:

> Dan,
>
> I can't comment on your particular flowgraph but I can tell you that you
> will get a significant speed-up if you build volk and GNURadio from source
> (and maybe fftw) as this enables all sorts off optimizations not in the ppa
> for compatability reasons.
>
> If you decide to go down this route I recommend you keep your root
> filesystem on an ssd attached via usb3 and increase your swap file size to
> max.
>
> Albin SM6WJM
>
> On Wed, Dec 16, 2020, 23:40 Dan Romanchik KB6NU  wrote:
>
>> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an
>> RTL-SDR dongle and thought it would be fun to experiment a little with GNU
>> Radio and learn something about SDR.
>>
>> A couple of days ago, I fired up GNU Radio, and after having some trouble
>> figuring out how to get the audio sink to talk to the Pi, I downloaded
>> VE6EY's FM receiver flow graph. The flow graph runs, but the Pi 4 just
>> doesn't seem to have enough horsepower to run it in real time. The audio is
>> slow and distorted.
>>
>> Thinking that it might be the WX widgets slowing down the program, I
>> first deleted the FFT display widgets, then converted the WX slider
>> controls to QT range controls. Neither had any effect on how well the flow
>> graph ran.
>>
>> GQRX and CubicSDDR seem to work just fine. At least with both of them,
>> I'm able to receive FM broadcast and NOAA weather station. But, maybe the
>> PI4 just doesn't have enough horsepower to run GNU Radio? If so, that's
>> kind of disappointing.
>>
>> 73! <—ham radio lingo for “best regards"
>>
>> *Dan KB6NU*
>> CW Geek, Ham Radio Instructor
>> Author of the "No Nonsense" amateur radio license study guides
>> Read my ham radio blog at http://www.kb6nu.com
>>
>

Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

Dan,

I can't comment on your particular flowgraph but I can tell you that you
will get a significant speed-up if you build volk and GNURadio from source
(and maybe fftw) as this enables all sorts off optimizations not in the ppa
for compatability reasons.

If you decide to go down this route I recommend you keep your root
filesystem on an ssd attached via usb3 and increase your swap file size to
max.

Albin SM6WJM

On Wed, Dec 16, 2020, 23:40 Dan Romanchik KB6NU  wrote:

> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an
> RTL-SDR dongle and thought it would be fun to experiment a little with GNU
> Radio and learn something about SDR.
>
> A couple of days ago, I fired up GNU Radio, and after having some trouble
> figuring out how to get the audio sink to talk to the Pi, I downloaded
> VE6EY's FM receiver flow graph. The flow graph runs, but the Pi 4 just
> doesn't seem to have enough horsepower to run it in real time. The audio is
> slow and distorted.
>
> Thinking that it might be the WX widgets slowing down the program, I first
> deleted the FFT display widgets, then converted the WX slider controls to
> QT range controls. Neither had any effect on how well the flow graph ran.
>
> GQRX and CubicSDDR seem to work just fine. At least with both of them, I'm
> able to receive FM broadcast and NOAA weather station. But, maybe the PI4
> just doesn't have enough horsepower to run GNU Radio? If so, that's kind of
> disappointing.
>
> 73! <—ham radio lingo for “best regards"
>
> *Dan KB6NU*
> CW Geek, Ham Radio Instructor
> Author of the "No Nonsense" amateur radio license study guides
> Read my ham radio blog at http://www.kb6nu.com
>

Re: GNU Radio on Raspberry Pi 4?

[jean-michel.fri...@femto-st.fr]

Forgot to Cc: the mailing list for the record:

> You will find at http://jmfriedt.free.fr/projetM1_2020_2.pdf the description
> of our use of the sound card of the Pi4 on slide 4. Prior to running the 
> sound card
> with GNU Radio, we tested with the speaker-test application by
> 1/ activating the sound card by adding in config.txt of the first VFAT 
> partition
> the option dtparam=audio=on
> 2/ when booting, the dmesg must display 
> bcm2835_audio bcm2835_audio: card created with 8 channels
> 3/ in buildroot, alsa-utils in Target packages -> Audio and video 
> applications provides
> speaker test and executing
> speaker-test -t sine -f 440
> should play a tone on the speaker output.
> 
> JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
> France
> 
> December 16, 2020 11:40 PM, "Dan Romanchik KB6NU"  wrote:
> 
>> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an 
>> RTL-SDR dongle and thought
>> it would be fun to experiment a little with GNU Radio and learn something 
>> about SDR.
>> 
>> A couple of days ago, I fired up GNU Radio, and after having some trouble 
>> figuring out how to get
>> the audio sink to talk to the Pi, I downloaded VE6EY's FM receiver flow 
>> graph. The flow graph runs,
>> but the Pi 4 just doesn't seem to have enough horsepower to run it in real 
>> time. The audio is slow
>> and distorted.
>> 
>> Thinking that it might be the WX widgets slowing down the program, I first 
>> deleted the FFT display
>> widgets, then converted the WX slider controls to QT range controls. Neither 
>> had any effect on how
>> well the flow graph ran.
>> 
>> GQRX and CubicSDDR seem to work just fine. At least with both of them, I'm 
>> able to receive FM
>> broadcast and NOAA weather station. But, maybe the PI4 just doesn't have 
>> enough horsepower to run
>> GNU Radio? If so, that's kind of disappointing.
>> 
>> 73! <—ham radio lingo for “best regards"
>> 
>> Dan KB6NU
>> CW Geek, Ham Radio Instructor
>> Author of the "No Nonsense" amateur radio license study guides
>> Read my ham radio blog at http://www.kb6nu.com

Re: GNU Radio on Raspberry Pi 4?

[Jeff Long]

I run a NBFM monitor 24x7 and it takes up a small fraction of a RPi3
(recording to files). It's likely that you are running across some sort of
rate/buffer problem, so keep trying!

On Wed, Dec 16, 2020 at 6:34 PM Fabien PELLET  wrote:

> Hello,
>
> I do not try to run GNUradio over my Pi4 for the moment but I encountered
> the problem you describe with the audio on a laptop.
>
> I solved it by specifying the name of the audio hardware (aplay -l as far
> as I remember in a terminal would help) and by checking the box for the
> blocking process.
>
> I hope it will help you,
> Best regards,
> Fabien, F4CTZ
>
>  Dan Romanchik KB6NU a écrit 
>
> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an
> RTL-SDR dongle and thought it would be fun to experiment a little with GNU
> Radio and learn something about SDR.
>
> A couple of days ago, I fired up GNU Radio, and after having some trouble
> figuring out how to get the audio sink to talk to the Pi, I downloaded
> VE6EY's FM receiver flow graph. The flow graph runs, but the Pi 4 just
> doesn't seem to have enough horsepower to run it in real time. The audio is
> slow and distorted.
>
> Thinking that it might be the WX widgets slowing down the program, I first
> deleted the FFT display widgets, then converted the WX slider controls to
> QT range controls. Neither had any effect on how well the flow graph ran.
>
> GQRX and CubicSDDR seem to work just fine. At least with both of them, I'm
> able to receive FM broadcast and NOAA weather station. But, maybe the PI4
> just doesn't have enough horsepower to run GNU Radio? If so, that's kind of
> disappointing.
>
> 73! <—ham radio lingo for “best regards"
>
> *Dan KB6NU*
> CW Geek, Ham Radio Instructor
> Author of the "No Nonsense" amateur radio license study guides
> Read my ham radio blog at http://www.kb6nu.com
>

Re: GNU Radio on Raspberry Pi 4?

[Fabien PELLET]

Hello,

I do not try to run GNUradio over my Pi4 for the moment but I encountered the 
problem you describe with the audio on a laptop.

I solved it by specifying the name of the audio hardware (aplay -l as far as I 
remember in a terminal would help) and by checking the box for the blocking 
process.

I hope it will help you,
Best regards, 
Fabien, F4CTZ 

 Dan Romanchik KB6NU a écrit 

>Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an 
>RTL-SDR dongle and thought it would be fun to experiment a little with 
>GNU Radio and learn something about SDR.
>
>A couple of days ago, I fired up GNU Radio, and after having some 
>trouble figuring out how to get the audio sink to talk to the Pi, I 
>downloaded VE6EY's FM receiver flow graph. The flow graph runs, but the 
>Pi 4 just doesn't seem to have enough horsepower to run it in real time. 
>The audio is slow and distorted.
>
>Thinking that it might be the WX widgets slowing down the program, I 
>first deleted the FFT display widgets, then converted the WX slider 
>controls to QT range controls. Neither had any effect on how well the 
>flow graph ran.
>
>GQRX and CubicSDDR seem to work just fine. At least with both of them, 
>I'm able to receive FM broadcast and NOAA weather station. But, maybe 
>the PI4 just doesn't have enough horsepower to run GNU Radio? If so, 
>that's kind of disappointing.
>
>73!<—ham radio lingo for “best regards"
>
>**Dan KB6NU**
>CW Geek, Ham Radio Instructor
>Author of the "No Nonsense" amateur radio license study guides
>Read my ham radio blog at http://www.kb6nu.com
>

GNU Radio on Raspberry Pi 4?

[Dan Romanchik KB6NU]

Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an 
RTL-SDR dongle and thought it would be fun to experiment a little with 
GNU Radio and learn something about SDR.


A couple of days ago, I fired up GNU Radio, and after having some 
trouble figuring out how to get the audio sink to talk to the Pi, I 
downloaded VE6EY's FM receiver flow graph. The flow graph runs, but the 
Pi 4 just doesn't seem to have enough horsepower to run it in real time. 
The audio is slow and distorted.


Thinking that it might be the WX widgets slowing down the program, I 
first deleted the FFT display widgets, then converted the WX slider 
controls to QT range controls. Neither had any effect on how well the 
flow graph ran.


GQRX and CubicSDDR seem to work just fine. At least with both of them, 
I'm able to receive FM broadcast and NOAA weather station. But, maybe 
the PI4 just doesn't have enough horsepower to run GNU Radio? If so, 
that's kind of disappointing.


73! <—ham radio lingo for “best regards"

**Dan KB6NU**
CW Geek, Ham Radio Instructor
Author of the "No Nonsense" amateur radio license study guides
Read my ham radio blog at http://www.kb6nu.com

Re: issue (qt gui range) after uninstalling GR 3.9 and installing 3.8.2.0 [solved]

[Christophe Seguinot]

  
  
Got it ! 

I had to remove ~/.cache/grc_gnuradio/cache.json
Regards, Christophe 

On 16/12/2020 18:50, Christophe
  Seguinot wrote:


  
  After further investigation I came to the conclusion that my
GRC (version 3.8.2.0) load 3.9 blocks. In my flowgraph, QT GUI
frequency sink has a 'Normalized window power' parameter which
has been introduced in GR 3.9. 
  
  This leads to the error : 
  
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
259, in __init__
    self.qtgui_freq_sink_x_0.set_fft_window_normalized(False)
AttributeError: 'freq_sink_c_sptr' object has no attribute
'set_fft_window_normalized'

  
  
 file
  /usr/share/gnuradio/grc/blocks/qtgui_freq_sink_x.block.yml is
  the 3.8.2.0 version, without the new 'Normalized window power"
  parameter
there is only one qtgui_freq_sink_x.block.yml on my PC

  
  
  
  
  
  
  
  

  

  

  

Hi 

I facing a simple issue on my Ubuntu 20.04 gnuradio 3.8.2.0
  install on one of my partition

I installed from ppa:gnuradio/gnuradio-releases on two
  different partition, both having Ubuntu 20.04 and the same PPA
  gnuradio version. Let's call these install P1 and P2:  


  P1 : GNURadio working
  P2 : first installed GR 3.9 from PPA, then uninstalled it
to revert to 3.8.2.0 (also tried to completely remove
3.8.2.0 an re-install it)
  

On P1, everything is working fine. 

On my P2 second partition I get this error : 


  Traceback (most recent call last):
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py",
line 205, in 
    main()
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py",
line 181, in main
    tb = top_block_cls()
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py",
line 86, in __init__
    self._Offset_freq_win =
RangeWidget(self._Offset_freq_range, self.set_Offset_freq,
'Corection frequence (ppm)', "counter_slider", float,
QtCore.Qt.Horizontal)
TypeError: __init__() takes from 5 to 6 positional arguments
but 7 were given
  

The error is simply caused by the last argument of the
RangeWidget call: QtCore.Qt.Horizontal. 

  the same flowgraph used on my first partition generates a
different and working top_block.py without this
QtCore.Qt.Horizontal argument (for every QT GUI Range
widget)
  the top_blosk.py when generated with P1 , then runned on
P2 (python3 ./topblock.py) works
  

So the issue clearly lays in the python script generation. 

Why is my P2 not generating the same top_block.py? It seems
  that There is something wrongly installed or some caching
  issue there (because of previously installed GR3.9 ?).  Does
  anyone could give me some hints to solve this? 

I already verified that I only get one file for range.py a
  qtgui_range.block.yml


  /usr/share/gnuradio/grc/blocks/qtgui_range.block.yml
  /usr/lib/python3/dist-packages/gnuradio/qtgui/range.py

These files seems identical in P1 and P2

Regards 





  

  

Re: issue (qt gui range) after uninstalling GR 3.9 and installing 3.8.2.0

[Christophe Seguinot]

  
  
After further investigation I came to the conclusion that my GRC
  (version 3.8.2.0) load 3.9 blocks. In my flowgraph, QT GUI
  frequency sink has a 'Normalized window power' parameter which has
  been introduced in GR 3.9. 

This leads to the error : 

File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line 259,
  in __init__
      self.qtgui_freq_sink_x_0.set_fft_window_normalized(False)
  AttributeError: 'freq_sink_c_sptr' object has no attribute
  'set_fft_window_normalized'
  


   file
/usr/share/gnuradio/grc/blocks/qtgui_freq_sink_x.block.yml is
the 3.8.2.0 version, without the new 'Normalized window power"
parameter
  there is only one qtgui_freq_sink_x.block.yml on my PC
  








  

  

  

  
  Hi 
  
  I facing a simple issue on my Ubuntu 20.04 gnuradio 3.8.2.0
install on one of my partition
  
  I installed from ppa:gnuradio/gnuradio-releases on two
different partition, both having Ubuntu 20.04 and the same PPA
gnuradio version. Let's call these install P1 and P2:  
  
  
P1 : GNURadio working
P2 : first installed GR 3.9 from PPA, then uninstalled it to
  revert to 3.8.2.0 (also tried to completely remove 3.8.2.0 an
  re-install it)

  
  On P1, everything is working fine. 
  
  On my P2 second partition I get this error : 
  
  
Traceback (most recent call last):
    File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
  205, in 
      main()
    File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
  181, in main
      tb = top_block_cls()
    File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
  86, in __init__
      self._Offset_freq_win =
  RangeWidget(self._Offset_freq_range, self.set_Offset_freq,
  'Corection frequence (ppm)', "counter_slider", float,
  QtCore.Qt.Horizontal)
  TypeError: __init__() takes from 5 to 6 positional arguments
  but 7 were given

  
  The error is simply caused by the last argument of the RangeWidget
  call: QtCore.Qt.Horizontal. 
  
the same flowgraph used on my first partition generates a
  different and working top_block.py without this
  QtCore.Qt.Horizontal argument (for every QT GUI Range widget)
the top_blosk.py when generated with P1 , then runned on P2
  (python3 ./topblock.py) works

  
  So the issue clearly lays in the python script generation. 
  
  Why is my P2 not generating the same top_block.py? It seems
that There is something wrongly installed or some caching issue
there (because of previously installed GR3.9 ?).  Does anyone
could give me some hints to solve this? 
  
  I already verified that I only get one file for range.py a
qtgui_range.block.yml
  
  
/usr/share/gnuradio/grc/blocks/qtgui_range.block.yml
/usr/lib/python3/dist-packages/gnuradio/qtgui/range.py
  
  These files seems identical in P1 and P2
  
  Regards 
  
  
  
  
  

  

Re: Regarding ofdm modulator and demodulator block

[Marcus Müller]

We still have the OFDM framework in GNU Radio 3.7, 3.8 and what will be 
3.9; You'll find examples in the gr-digital examples folder! (typically, 
/usr/share/gnuradio/examples/digital or somewhere similar)


Also, don't forget that *generating* an OFDM signal is really, really 
simple with the FFT block, stream to vector, vector to stream, and a 
single block that you could write yourself that inserts the cyclic 
prefix. Your task is surely to *understand* OFDM, so maybe plugging 
something together that gives you a valid CP-OFDM signal is what your 
advisor wants you to do?


Best regards,
Marcus

On 16/12/2020 18.08, Rozana Alam wrote:

Dear community,
Is the ofdm modulator and demodulator block removed from the gnu radio 
3.7.0 version? I want to analyse simple ofdm modulated signal in 
different frequency and bandwidth using spectrum analyser and usrp. 
Please help me with your guidance on this, as a beginner with gnu radio 
and SDR I really need your suggestion.

Thank you.
Sincerely,
Rozana

Regarding ofdm modulator and demodulator block

[Rozana Alam]

Dear community,
Is the ofdm modulator and demodulator block removed from the gnu radio
3.7.0 version? I want to analyse simple ofdm modulated signal in different
frequency and bandwidth using spectrum analyser and usrp. Please help me
with your guidance on this, as a beginner with gnu radio and SDR I really
need your suggestion.
Thank you.
Sincerely,
Rozana

Re: issue (qt gui range) after uninstalling GR 3.9 and installing 3.8.2.0

[Christophe Seguinot]

  
  
I found this closed
issue on gnruradio github. with a solution which solved my
  issue. 

Meanwhile I don't understand why I got this erroneous
  /usr/share/gnuradio/grc/blocks/qtgui_range.block.yml file !

 

On 16/12/2020 14:35, Christophe
  Seguinot wrote:


  
  Hi 
  
  I facing a simple issue on my Ubuntu 20.04 gnuradio 3.8.2.0
install on one of my partition
  
  I installed from ppa:gnuradio/gnuradio-releases on two
different partition, both having Ubuntu 20.04 and the same PPA
gnuradio version. Let's call these install P1 and P2:  
  
  
P1 : GNURadio working
P2 : first installed GR 3.9 from PPA, then uninstalled it to
  revert to 3.8.2.0 (also tried to completely remove 3.8.2.0 an
  re-install it)

  
  On P1, everything is working fine. 
  
  On my P2 second partition I get this error : 
  
  
Traceback (most recent call last):
    File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
  205, in 
      main()
    File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
  181, in main
      tb = top_block_cls()
    File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
  86, in __init__
      self._Offset_freq_win =
  RangeWidget(self._Offset_freq_range, self.set_Offset_freq,
  'Corection frequence (ppm)', "counter_slider", float,
  QtCore.Qt.Horizontal)
  TypeError: __init__() takes from 5 to 6 positional arguments
  but 7 were given

  
  The error is simply caused by the last argument of the RangeWidget
  call: QtCore.Qt.Horizontal. 
  
the same flowgraph used on my first partition generates a
  different and working top_block.py without this
  QtCore.Qt.Horizontal argument (for every QT GUI Range widget)
the top_blosk.py when generated with P1 , then runned on P2
  (python3 ./topblock.py) works

  
  So the issue clearly lays in the python script generation. 
  
  Why is my P2 not generating the same top_block.py? It seems
that There is something wrongly installed or some caching issue
there (because of previously installed GR3.9 ?).  Does anyone
could give me some hints to solve this? 
  
  I already verified that I only get one file for range.py a
qtgui_range.block.yml
  
  
/usr/share/gnuradio/grc/blocks/qtgui_range.block.yml
/usr/lib/python3/dist-packages/gnuradio/qtgui/range.py
  
  These files seems identical in P1 and P2
  
  Regards 
  
  
  
  
  

  

Re: RPC Timeout with USRP N321

[Martin Braun]

It looks like the device is not properly initialized. Things to make sure:
- You're running UHD 3 on your host. Are you running UHD 3 on your device?
- It's not clear if there is a specific issue with get_num_xbars(), or if
there's a general RPC problem. Does uhd_usrp_probe work?

--M

On Fri, Dec 11, 2020 at 11:06 PM Dylan Baros  wrote:

> Good afternoon,
>
> Sent a message yesterday but I realize that it was not complete so I
> apologize. The issue is that I am getting the following error message when
> doing the spectrum analyzer tutorial on the gnuradio website.
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations
> Guided Tutorial Hardware Considerations - GNU Radio
> 
> Introduction []. One of the more basic (and also incredibly useful) things
> you can do in GNU Radio with a receiver is to create a software radio
> spectrum analyzer.
> wiki.gnuradio.org
>
>
> Generating: '/home/dylan/Documents/sa1.py'
>
> Executing: /usr/bin/python3 -u /home/dylan/Documents/sa1.py
>
> [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100;
> UHD_3.15.0.0-2build5
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=n3xx,product=n320,serial=31EDB79,claimed=False,addr=192.168.10.2
> Traceback (most recent call last):
>   File "/home/dylan/Documents/sa1.py", line 199, in 
> main()
>   File "/home/dylan/Documents/sa1.py", line 175, in main
> tb = top_block_cls()
>   File "/home/dylan/Documents/sa1.py", line 92, in __init__
> self.uhd_usrp_source_0 = uhd.usrp_source(
>   File "/usr/lib/python3/dist-packages/gnuradio/uhd/__init__.py", line
> 125, in constructor_interceptor
> return old_constructor(*args)
>   File "/usr/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 2787, in make
> return _uhd_swig.usrp_source_make(device_addr, stream_args,
> issue_stream_cmd_on_start)
> RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
> 'get_num_xbars'
>
> >>> Done (return code 1)
>
> I am using a USRP N321 and N320.
>
>
> Any ideas? Thanks.
>

issue (qt gui range) after uninstalling GR 3.9 and installing 3.8.2.0

[Christophe Seguinot]

  
  
Hi 

I facing a simple issue on my Ubuntu 20.04 gnuradio 3.8.2.0
  install on one of my partition

I installed from ppa:gnuradio/gnuradio-releases on two different
  partition, both having Ubuntu 20.04 and the same PPA gnuradio
  version. Let's call these install P1 and P2:  


  P1 : GNURadio working
  P2 : first installed GR 3.9 from PPA, then uninstalled it to
revert to 3.8.2.0 (also tried to completely remove 3.8.2.0 an
re-install it)
  

On P1, everything is working fine. 

On my P2 second partition I get this error : 


  Traceback (most recent call last):
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
205, in 
    main()
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
181, in main
    tb = top_block_cls()
  File "/home/seguinot/Bureau/gilles_rubin/top_block.py", line
86, in __init__
    self._Offset_freq_win = RangeWidget(self._Offset_freq_range,
self.set_Offset_freq, 'Corection frequence (ppm)',
"counter_slider", float, QtCore.Qt.Horizontal)
TypeError: __init__() takes from 5 to 6 positional arguments but
7 were given
  

The error is simply caused by the last argument of the RangeWidget
call: QtCore.Qt.Horizontal. 

  the same flowgraph used on my first partition generates a
different and working top_block.py without this
QtCore.Qt.Horizontal argument (for every QT GUI Range widget)
  the top_blosk.py when generated with P1 , then runned on P2
(python3 ./topblock.py) works
  

So the issue clearly lays in the python script generation. 

Why is my P2 not generating the same top_block.py? It seems that
  There is something wrongly installed or some caching issue there
  (because of previously installed GR3.9 ?).  Does anyone could give
  me some hints to solve this? 

I already verified that I only get one file for range.py a
  qtgui_range.block.yml


  /usr/share/gnuradio/grc/blocks/qtgui_range.block.yml
  /usr/lib/python3/dist-packages/gnuradio/qtgui/range.py


These files seems identical in P1 and P2

Regards 





  

Re: Porting gr-osmosdr to gr-3.9 without swig.

[Christophe Seguinot]

Hi Volker

Did you succeeded in porting gr-osmosdr to GR3.9 ? Do you have some 
repository for this ?


Regards, Christophe


On 14/09/2020 17:10, Volker Schroer wrote:

Hi Chris,

I started gr-osmosdr some month ago, but I had to interrupt due to other
coding needs.

What gr-osmosdr repository did you start with ?
I forked
https://github.com/argilo/gr-osmosdr.git

which had some preparations for 3.9, but at that time gr3.9 still used 
swig.


First I ported successfully some of my oot modules to 3.9 the way
described in the porting guide.

But for more complex modules I tried another way.

I removed the swig part and looked at my ported modules, how to add the
pybind part.

At the moment I'm at the point af generating the bindings.

-- Volker