GNU Radio, One Step at a Time: August 2020

Monday, August 31, 2020

Re: how to run gdb with gnuradio 3.8 ?

On 08/31/2020 07:34 PM, Jeff Long wrote:
> If the console window in GRC were interactive, then you could debug
> right there, using gdb as the interpreter. I spent a grand total of 5
> minutes looking into this, so maybe this is already possible. There's
> no particular advantage to doing it this way, though, since we assume
> that the user is fairly advanced if they're debugging an OOT ... the
> usual reason for not wanting to leave the GRC environment doesn't apply.
>
If you're a developer and the thought of popping out to an ordinary
command-line frightens you, you must be a Visual Studio user :) :)

[I'll, ahem, go back to my troll cave].

Re: how to run gdb with gnuradio 3.8 ?

If the console window in GRC were interactive, then you could debug right there, using gdb as the interpreter. I spent a grand total of 5 minutes looking into this, so maybe this is already possible. There's no particular advantage to doing it this way, though, since we assume that the user is fairly advanced if they're debugging an OOT ... the usual reason for not wanting to leave the GRC environment doesn't apply.

On Mon, Aug 31, 2020 at 7:20 PM Marcus Müller <mmueller@gnuradio.org> wrote:

Interact in which way, enabling what? Maybe I / we have some hints :)

On 31.08.20 22:52, Jeff Long wrote:
> You can run the python interpreter under gdb, outside GRC, and that should
> capture library errors. Another stranger idea would be to change the
> "interpreter" under GRC options/advanced to run your program under GDB. I
> got this to work using something along the lines of:
>
> gdb {python} -ex "run -u {filename}"
>
> but didn't figure out how to interact with GDB afterward if that were to be
> necessary.
>
> On Mon, Aug 31, 2020 at 4:30 PM Tom McDermott <tom.n5eg@gmail.com> wrote:
>
>> I am trying to debug an OOT in gnuradio 3.8 using gdb. It's a problem
>> with double free()
>> that seems to have popped up with 3.8.2
>>
>> I rebuilt my OOT with debug symbols. WIthout gdb, it all runs, but of
>> course tells me about the double free() when it shuts down.
>>
>> 1. I've altered the top_block.py to stop and wait after printing the
>> process id before continuing,
>> then enter to continue. This starts up the flowgraph GUI.
>>
>> 2. In a different terminal window:
>> $ sudo gdb -p the_process_id
>> This makes the gui disappear, and 'System Problem Detected' window
>> appears asking
>> if I want to report the problem.
>>
>> I still have the gdb window, but because I was not able to shut down my
>> GUI, the
>> backtrace does not let me look at the shutdown error I am getting.
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>
>>
>>
>

Re: how to run gdb with gnuradio 3.8 ?

Interact in which way, enabling what? Maybe I / we have some hints :)

On 31.08.20 22:52, Jeff Long wrote:
> You can run the python interpreter under gdb, outside GRC, and that should
> capture library errors. Another stranger idea would be to change the
> "interpreter" under GRC options/advanced to run your program under GDB. I
> got this to work using something along the lines of:
>
> gdb {python} -ex "run -u {filename}"
>
> but didn't figure out how to interact with GDB afterward if that were to be
> necessary.
>
> On Mon, Aug 31, 2020 at 4:30 PM Tom McDermott <tom.n5eg@gmail.com> wrote:
>
>> I am trying to debug an OOT in gnuradio 3.8 using gdb. It's a problem
>> with double free()
>> that seems to have popped up with 3.8.2
>>
>> I rebuilt my OOT with debug symbols. WIthout gdb, it all runs, but of
>> course tells me about the double free() when it shuts down.
>>
>> 1. I've altered the top_block.py to stop and wait after printing the
>> process id before continuing,
>> then enter to continue. This starts up the flowgraph GUI.
>>
>> 2. In a different terminal window:
>> $ sudo gdb -p the_process_id
>> This makes the gui disappear, and 'System Problem Detected' window
>> appears asking
>> if I want to report the problem.
>>
>> I still have the gdb window, but because I was not able to shut down my
>> GUI, the
>> backtrace does not let me look at the shutdown error I am getting.
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>
>>
>>
>

R: R: R: R: Funcube Dongle Pro Plus help

Thanks Marcus,
it worked no Missing blocks now but when I go to run the Funcube grc file I get tis on the bottom:

Generating: '/media/enzo/243A-C1DB/BY70-2/BY70-2/frontend_by702_rx_fcdpp.py'

Executing: /usr/bin/python3 -u /media/enzo/243A-C1DB/BY70-2/BY70-2/frontend_by702_rx_fcdpp.py

Traceback (most recent call last):
File "/media/enzo/243A-C1DB/BY70-2/BY70-2/frontend_by702_rx_fcdpp.py", line 366, in <module>
main()
File "/media/enzo/243A-C1DB/BY70-2/BY70-2/frontend_by702_rx_fcdpp.py", line 342, in main
tb = top_block_cls()
File "/media/enzo/243A-C1DB/BY70-2/BY70-2/frontend_by702_rx_fcdpp.py", line 266, in __init__
self.fcdproplus_fcdproplus_0 = fcdproplus.fcdproplus('',1)
File "/usr/local/lib/python3/dist-packages/fcdproplus/fcdproplus_swig.py", line 121, in make
return _fcdproplus_swig.fcdproplus_make(*args, **kwargs)
RuntimeError: Alsa not found.

>>> Done (return code 1)

And it does not run.
Any advice please?
Thanks

73's de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520

*********************************
****** GSM +39 328 7110193 ******
***** SMS +39 328 7110193 *****
*********************************

> -----Messaggio originale-----
> Da: Marcus Müller <mueller@kit.edu>
> Inviato: lunedì 31 agosto 2020 20:44
> A: Vincenzo Mone <vimone@alice.it>
> Oggetto: Re: R: R: R: Funcube Dongle Pro Plus help
>
> Vincenzo,
>
> CC. gnuradio-discuss@gnu.org.
>
> Respectfully,
> Marcus
>
> On 31/08/2020 20.42, Vincenzo Mone wrote:
> > Marcus,
> > i have retried againd with the command you said deleting the gr-fcdproplus
> folder and restarting.
> > When I run make I have noticed at the end this:
> >
> > warning: Tag 'PERL_PATH' at line 1686 of file '/home/enzo/gr-
> fcdproplus/build/docs/doxygen/Doxyfile' has become obsolete.
> > To avoid this warning please remove this line from your configuration
> file or upgrade it using "doxygen -u"
> > warning: Tag 'MSCGEN_PATH' at line 1707 of file '/home/enzo/gr-
> fcdproplus/build/docs/doxygen/Doxyfile' has become obsolete.
> > To avoid this warning please remove this line from your configuration
> file or upgrade it using "doxygen -u"
> > [100%] Built target doxygen_target
> >
> > Is it normal?????
> >
> > 73's de Enzo IK8OZV
> > EasyLog 5 BetaTester
> > EasyLog PDA BetaTester
> > WinBollet BetaTester
> > D.C.I. CheckPoint Regione Campania
> > Skype: ik8ozv8520
> >
> >
> >
> >
> > *********************************
> > ****** GSM +39 328 7110193 ******
> > ***** SMS +39 328 7110193 *****
> > *********************************
> >
> >> -----Messaggio originale-----
> >> Da: Marcus Müller <mueller@kit.edu>
> >> Inviato: lunedì 31 agosto 2020 20:26
> >> A: Vincenzo Mone <vimone@alice.it>
> >> Cc: Gnuradio Mailing List <discuss-gnuradio@gnu.org>
> >> Oggetto: Re: R: R: Funcube Dongle Pro Plus help
> >>
> >> You need to be more careful, Vincenzo. The space between = and " is
> wrong.
> >> There mustn't be any space. It should be:
> >>
> >> cmake -DCMAKE_INSTALL_PREFIX="/usr/local/" ../
> >>
> >> Best regards,
> >> Marcus
> >>
> >> On 31/08/2020 20.18, Vincenzo Mone wrote:
> >>> Hi Marcus,
> >>> thanks for your reply.
> >>> I gave the command:
> >>>
> >>> gnuradio-config-info --prefix
> >>>
> >>> and got :
> >>>
> >>> /usr/local
> >>>
> >>> So I have tried to give the command:
> >>>
> >>> cmake -DCMAKE_INSTALL_PREFIX= "/usr/local/" ../
> >>>
> >>> - Checking for module 'mpir >= 3.0'
> >>> -- No package 'mpir' found
> >>> -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
> >>> MPIR_INCLUDE_DIR)
> >>> -- User set python executable /usr/bin/python3
> >>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so
> >>> (found suitable exact version "3.8.2")
> >>> -- Found ALSA 1.2.2
> >>> -- Found jack: /usr/lib/x86_64-linux-gnu/libjack.so
> >>> -- Extracting version information from git describe...
> >>> -- System Hidapi will be used
> >>>
> >

Re: how to run gdb with gnuradio 3.8 ?

You can run the python interpreter under gdb, outside GRC, and that should capture library errors. Another stranger idea would be to change the "interpreter" under GRC options/advanced to run your program under GDB. I got this to work using something along the lines of:

gdb {python} -ex "run -u {filename}"

but didn't figure out how to interact with GDB afterward if that were to be necessary.

On Mon, Aug 31, 2020 at 4:30 PM Tom McDermott <tom.n5eg@gmail.com> wrote:

I am trying to debug an OOT in gnuradio 3.8 using gdb. It's a problem with double free()
that seems to have popped up with 3.8.2

I rebuilt my OOT with debug symbols. WIthout gdb, it all runs, but of course tells me about the double free() when it shuts down.

1. I've altered the top_block.py to stop and wait after printing the process id before continuing,
then enter to continue. This starts up the flowgraph GUI.

2. In a different terminal window:
$ sudo gdb -p the_process_id
This makes the gui disappear, and 'System Problem Detected' window appears asking
if I want to report the problem.

I still have the gdb window, but because I was not able to shut down my GUI, the
backtrace does not let me look at the shutdown error I am getting.

-- Tom, N5EG

how to run gdb with gnuradio 3.8 ?

I am trying to debug an OOT in gnuradio 3.8 using gdb. It's a problem with double free()

that seems to have popped up with 3.8.2

I rebuilt my OOT with debug symbols. WIthout gdb, it all runs, but of course tells me about the double free() when it shuts down.

1. I've altered the top_block.py to stop and wait after printing the process id before continuing,

then enter to continue. This starts up the flowgraph GUI.

2. In a different terminal window:

$ sudo gdb -p the_process_id

This makes the gui disappear, and 'System Problem Detected' window appears asking

if I want to report the problem.

I still have the gdb window, but because I was not able to shut down my GUI, the

backtrace does not let me look at the shutdown error I am getting.

-- Tom, N5EG

Re: R: R: Funcube Dongle Pro Plus help

You need to be more careful, Vincenzo. The space between = and " is
wrong. There mustn't be any space. It should be:

cmake -DCMAKE_INSTALL_PREFIX="/usr/local/" ../

Best regards,
Marcus

On 31/08/2020 20.18, Vincenzo Mone wrote:
> Hi Marcus,
> thanks for your reply.
> I gave the command:
>
> gnuradio-config-info --prefix
>
> and got :
>
> /usr/local
>
> So I have tried to give the command:
>
> cmake -DCMAKE_INSTALL_PREFIX= "/usr/local/" ../
>
> - Checking for module 'mpir >= 3.0'
> -- No package 'mpir' found
> -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
> -- User set python executable /usr/bin/python3
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found suitable exact version "3.8.2")
> -- Found ALSA 1.2.2
> -- Found jack: /usr/lib/x86_64-linux-gnu/libjack.so
> -- Extracting version information from git describe...
> -- System Hidapi will be used
>

R: R: Funcube Dongle Pro Plus help

Hi Marcus,
thanks for your reply.
I gave the command:

gnuradio-config-info --prefix

and got :

/usr/local

So I have tried to give the command:

cmake -DCMAKE_INSTALL_PREFIX= "/usr/local/" ../

- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
-- User set python executable /usr/bin/python3
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found suitable exact version "3.8.2")
-- Found ALSA 1.2.2
-- Found jack: /usr/lib/x86_64-linux-gnu/libjack.so
-- Extracting version information from git describe...
-- System Hidapi will be used
--
-- Checking for module SWIG
-- Found SWIG version 4.0.1.
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found version "3.8.2")
-- Doxxyfile found in /usr/share/gnuradio/modtool/templates/gr-newmod/docs/doxygen
-- ================ Build Summary =========================
-- Building gr-fcdproplus : 3.8.0 for Linux
-- Building for gnuradio : 3.8.1.0
-- Using CMAKE Module path : /home/enzo/gr-fcdproplus/cmake/Modules;/usr/local/lib/cmake/gnuradio
-- CMake Modules Dir : lib/cmake
-- fcdproplus INCLUDES : include/fcdproplus
-- Using install prefix :
-- Installing grc files to : /share/gnuradio/grc/blocks
-- System Hidapi Lib /usr/lib/x86_64-linux-gnu/libhidapi-libusb.so is used
-- ========================================================
-- Configuring done
-- Generating done
-- Build files have been written to: /home/enzo/gr-fcdproplus/build

Then I gave the other commands:

make
sudo make install
sudo ldconfig

Did not get any errors on the above commands

Went again in gnuradio but still get the missing block fcdproplus_fcdproplus
Thanks

73's de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520

*********************************
****** GSM +39 328 7110193 ******
***** SMS +39 328 7110193 *****
*********************************

> -----Messaggio originale-----
> Da: Marcus Müller <mueller@kit.edu>
> Inviato: lunedì 31 agosto 2020 19:37
> A: Vincenzo Mone <vimone@alice.it>
> Cc: Gnuradio Mailing List <discuss-gnuradio@gnu.org>
> Oggetto: Re: R: Funcube Dongle Pro Plus help
>
> Hi Vincenzo,
>
> no such thing as "closed" :)
>
> Well, that path is where your GNU Radio is installed to. You should be able to
> check it through `gnuradio-config-info --prefix`.
>
> To repeat my questions:
>
> 1. Did `cmake...` run through successfully? Or did it end with an error?
>
> 2. Did `make` run through successfully? Or did it end with an error?
>
> 3. Did `sudo make install` run through successfully? Or did it end with an
> error?
>
> Best regards,
> Marcus
>
> On 8/31/20 7:25 PM, Vincenzo Mone wrote:
> > Sorry Marcus,
> > I thought it was closed as I did not get any reply from a long time.
> > Please what I need to check as I still did not understood how to know
> > The gnuradio path for the correct command:
> >
> > cmake -DCMAKE_INSTALL_PREFIX= "path to gnuradio installation" ../
> >
> > Thanks
> >
> > 73's de Enzo IK8OZV
> > EasyLog 5 BetaTester
> > EasyLog PDA BetaTester
> > WinBollet BetaTester
> > D.C.I. CheckPoint Regione Campania
> > Skype: ik8ozv8520
> >
> >
> >
> >
> > *********************************
> > ****** GSM +39 328 7110193 ******
> > ***** SMS +39 328 7110193 *****
> > *********************************
> >
> >> -----Messaggio originale-----
> >> Da: Marcus Müller <mueller@kit.edu>
> >> Inviato: lunedì 31 agosto 2020 18:11
> >> A: Vincenzo Mone <vimone@alice.it>; Gnuradio Mailing List <discuss-
> >> gnuradio@gnu.org>
> >> Oggetto: Re: Funcube Dongle Pro Plus help
> >>
> >> Vincenzo,
> >>
> >> please don't open a new thread for every other email you have sent.
> >> You have gotten easily confused in the past, and we can avoid that if
> >> you can
> > try
> >> to focus on staying on a single email thread, and it was a big
> >> problem for
> > you.
> >> Please don't open a new thread before having solved this issue, and
> > instead
> >> reply to the things here, keeping discuss-gnuradio@gnu.org in CC:.
> >>
> >> Something went wrong during your software build or installation. We
> >> can't tell you what that was - have you checked whether the cmake,
> >> the make, the make install commands were successful?
> >>
> >> Best regards,
> >>
> >> Marcus
> >>
> >> On 8/31/20 5:09 PM, Vincenzo Mone wrote:
> >>> Hello
> >>>
> >>> Please I am trying to install the FCDPROPLUS which is the Funcube
> >>> Dongle Pro Plus.
> >>>
> >>> This is what I've done following the instructions on the author page:
> >>>
> >>> git clone https://github.com/dl1ksv/gr-fcdproplus
> >>>
> >>> cd ~/gr-fcdproplus
> >>>
> >>> mkdir build
> >>>
> >>> cd build
> >>>
> >>> cmake -DCMAKE_INSTALL_PREFIX="/usr" -
> DCMAKE_BUILD_TYPE=Release
> >> ../
> >>> make
> >>>
> >>> sudo make install
> >>>
> >>> sudo ldconfig
> >>>
> >>> then I have created a file named '99-usb-serial.rules' with the
> >>> following content:
> >>>
> >>> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
> >> ATTRS{idProduct}=="fb56"
> >>> MODE:="0666"
> >>>
> >>> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
> >> ATTRS{idProduct}=="fb31"
> >>> MODE:="0666"
> >>>
> >>> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
> >>> ATTRS{idProduct}=="fb56", MODE="0666"
> >>>
> >>> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
> >>> ATTRS{idProduct}=="fb
> >>>
> >>> Then:
> >>>
> >>> cd /etc/udev/rules.d
> >>>
> >>> sudo cp -v ~/<your folder>/99-usb-serial.rules ./
> >>>
> >>> sudo udevadm trigger
> >>>
> >>> After that executing grc I sould find in Fcd
> >>>
> >>> Funcube Dongle
> >>>
> >>> Funcube Dongle control
> >>>
> >>> Funcube Dongle Pro+
> >>>
> >>> Funcube Dongle Pro+ control
> >>>
> >>> But I do not find any FCD group.
> >>>
> >>> Please anybody can tell me if I am doing something wrong?
> >>>
> >>> Thanks
> >>>
> >>> 73's de Enzo IK8OZV
> >>> EasyLog 5 BetaTester
> >>> EasyLog PDA BetaTester
> >>> WinBollet BetaTester
> >>> D.C.I. CheckPoint Regione Campania
> >>> Skype: ik8ozv8520
> >>>
> >>>
> >>>
> >>>
> >>> *********************************
> >>>
> >>> ****** GSM +39 328 7110193 ******
> >>>
> >>> ***** SMS +39 328 7110193 *****
> >>>
> >>> *********************************
> >>>

Re: R: Funcube Dongle Pro Plus help

Hi Vincenzo,

no such thing as "closed" :)

Well, that path is where your GNU Radio is installed to. You should be
able to check it through `gnuradio-config-info --prefix`.

To repeat my questions:

1. Did `cmake...` run through successfully? Or did it end with an error?

2. Did `make` run through successfully? Or did it end with an error?

3. Did `sudo make install` run through successfully? Or did it end with
an error?

Best regards,
Marcus

On 8/31/20 7:25 PM, Vincenzo Mone wrote:
> Sorry Marcus,
> I thought it was closed as I did not get any reply from a long time.
> Please what I need to check as I still did not understood how to know The
> gnuradio path for the correct command:
>
> cmake -DCMAKE_INSTALL_PREFIX= "path to gnuradio installation" ../
>
> Thanks
>
> 73's de Enzo IK8OZV
> EasyLog 5 BetaTester
> EasyLog PDA BetaTester
> WinBollet BetaTester
> D.C.I. CheckPoint Regione Campania
> Skype: ik8ozv8520
>
>
>
>
>       *********************************
>       ****** GSM +39 328 7110193 ******
>       ***** SMS +39 328 7110193 *****
>       *********************************
>
>> -----Messaggio originale-----
>> Da: Marcus Müller <mueller@kit.edu>
>> Inviato: lunedì 31 agosto 2020 18:11
>> A: Vincenzo Mone <vimone@alice.it>; Gnuradio Mailing List <discuss-
>> gnuradio@gnu.org>
>> Oggetto: Re: Funcube Dongle Pro Plus help
>>
>> Vincenzo,
>>
>> please don't open a new thread for every other email you have sent. You
>> have gotten easily confused in the past, and we can avoid that if you can
> try
>> to focus on staying on a single email thread, and it was a big problem for
> you.
>> Please don't open a new thread before having solved this issue, and
> instead
>> reply to the things here, keeping discuss-gnuradio@gnu.org in CC:.
>>
>> Something went wrong during your software build or installation. We can't
>> tell you what that was - have you checked whether the cmake, the make,
>> the make install commands were successful?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 8/31/20 5:09 PM, Vincenzo Mone wrote:
>>> Hello
>>>
>>> Please I am trying to install the FCDPROPLUS which is the Funcube
>>> Dongle Pro Plus.
>>>
>>> This is what I've done following the instructions on the author page:
>>>
>>> git clone https://github.com/dl1ksv/gr-fcdproplus
>>>
>>> cd ~/gr-fcdproplus
>>>
>>> mkdir build
>>>
>>> cd build
>>>
>>> cmake -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE=Release
>> ../
>>> make
>>>
>>> sudo make install
>>>
>>> sudo ldconfig
>>>
>>> then I have created a file named '99-usb-serial.rules' with the
>>> following content:
>>>
>>> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
>> ATTRS{idProduct}=="fb56"
>>> MODE:="0666"
>>>
>>> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
>> ATTRS{idProduct}=="fb31"
>>> MODE:="0666"
>>>
>>> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
>>> ATTRS{idProduct}=="fb56", MODE="0666"
>>>
>>> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
>>> ATTRS{idProduct}=="fb
>>>
>>> Then:
>>>
>>> cd /etc/udev/rules.d
>>>
>>> sudo cp -v ~/<your folder>/99-usb-serial.rules ./
>>>
>>> sudo udevadm trigger
>>>
>>> After that executing grc I sould find in Fcd
>>>
>>> Funcube Dongle
>>>
>>> Funcube Dongle control
>>>
>>> Funcube Dongle Pro+
>>>
>>> Funcube Dongle Pro+ control
>>>
>>> But I do not find any FCD group.
>>>
>>> Please anybody can tell me if I am doing something wrong?
>>>
>>> Thanks
>>>
>>> 73's de Enzo IK8OZV
>>> EasyLog 5 BetaTester
>>> EasyLog PDA BetaTester
>>> WinBollet BetaTester
>>> D.C.I. CheckPoint Regione Campania
>>> Skype: ik8ozv8520
>>>
>>>
>>>
>>>
>>> *********************************
>>>
>>> ****** GSM +39 328 7110193 ******
>>>
>>>       *****     SMS +39 328 7110193 *****
>>>
>>>       *********************************
>>>

R: Funcube Dongle Pro Plus help

Sorry Marcus,
I thought it was closed as I did not get any reply from a long time.
Please what I need to check as I still did not understood how to know The
gnuradio path for the correct command:

cmake -DCMAKE_INSTALL_PREFIX= "path to gnuradio installation" ../

Thanks

73's de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520

      *********************************
      ****** GSM +39 328 7110193 ******
      ***** SMS +39 328 7110193 *****
      *********************************

> -----Messaggio originale-----
> Da: Marcus Müller <mueller@kit.edu>
> Inviato: lunedì 31 agosto 2020 18:11
> A: Vincenzo Mone <vimone@alice.it>; Gnuradio Mailing List <discuss-
> gnuradio@gnu.org>
> Oggetto: Re: Funcube Dongle Pro Plus help
>
> Vincenzo,
>
> please don't open a new thread for every other email you have sent. You
> have gotten easily confused in the past, and we can avoid that if you can
try
> to focus on staying on a single email thread, and it was a big problem for
you.
> Please don't open a new thread before having solved this issue, and
instead
> reply to the things here, keeping discuss-gnuradio@gnu.org in CC:.
>
> Something went wrong during your software build or installation. We can't
> tell you what that was - have you checked whether the cmake, the make,
> the make install commands were successful?
>
> Best regards,
>
> Marcus
>
> On 8/31/20 5:09 PM, Vincenzo Mone wrote:
> >
> > Hello
> >
> > Please I am trying to install the FCDPROPLUS which is the Funcube
> > Dongle Pro Plus.
> >
> > This is what I've done following the instructions on the author page:
> >
> > git clone https://github.com/dl1ksv/gr-fcdproplus
> >
> > cd ~/gr-fcdproplus
> >
> > mkdir build
> >
> > cd build
> >
> > cmake -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE=Release
> ../
> >
> > make
> >
> > sudo make install
> >
> > sudo ldconfig
> >
> > then I have created a file named '99-usb-serial.rules' with the
> > following content:
> >
> > SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
> ATTRS{idProduct}=="fb56"
> > MODE:="0666"
> >
> > SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
> ATTRS{idProduct}=="fb31"
> > MODE:="0666"
> >
> > KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
> > ATTRS{idProduct}=="fb56", MODE="0666"
> >
> > KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
> > ATTRS{idProduct}=="fb
> >
> > Then:
> >
> > cd /etc/udev/rules.d
> >
> > sudo cp -v ~/<your folder>/99-usb-serial.rules ./
> >
> > sudo udevadm trigger
> >
> > After that executing grc I sould find in Fcd
> >
> > Funcube Dongle
> >
> > Funcube Dongle control
> >
> > Funcube Dongle Pro+
> >
> > Funcube Dongle Pro+ control
> >
> > But I do not find any FCD group.
> >
> > Please anybody can tell me if I am doing something wrong?
> >
> > Thanks
> >
> > 73's de Enzo IK8OZV
> > EasyLog 5 BetaTester
> > EasyLog PDA BetaTester
> > WinBollet BetaTester
> > D.C.I. CheckPoint Regione Campania
> > Skype: ik8ozv8520
> >
> >
> >
> >
> > *********************************
> >
> > ****** GSM +39 328 7110193 ******
> >
> >       *****     SMS +39 328 7110193 *****
> >
> >       *********************************
> >

Reed Solomon - Certain setting decodes with errors

Hello,

I have a flow graph that makes use of Reed Solomon encoding for a portion of the error correction and I noticed an odd issue with certain values. Under certain settings the Reed Solomon Decoder output has errors under a clean channel. The errors seem to be related to packing the output from the encoder and then immediately unpacking the output for the encoder. However if you change the settings the pack/unpack does not have the same effect. Can anyone help me narrow down the root cause of my issue? Right now I am using alternative settings, but I would prefer to correct the issue.

Thank you,

Tim

Re: Using forgotten id breaks gnuradio-companion

I'd categorize this somewhere between feature request and bug report.

Could you raise this as an issue on github.com/gnuradio/gnuradio/issues
, please?

Generally, tracking could be possible, but is rather complicated,
because we have different namespaces in which parts of the flow graph
generation happen. Hence, I'd like this to be tracked in the issue
tracker. Thanks!

Best,

Marcus

On 8/31/20 4:52 PM, Christophe Seguinot wrote:
> Hi
>
> One of my flowgraph was generating the error:
>
> self.audio_sink_0 = audio.sink(audio_rate, '', True)
> AttributeError: 'int' object has no attribute 'sink'
>
> This error was not easy to debug since the error message sounds like
> there was a library error (which was not the case here).
>
> My mistake was a "QT GUI Chooser" whose id was (incorrectly) set to
> audio; "audio" being also the name of a gnuradio python module.
>
> Now that I found my mistake, it's obvious that no ID should be set to
> some python module name.
>
> May be it could be interesting that gnuradio-companion tests block ids
> and rejects forbidden ones when compiling flowgraph.
>
> Regards
>
>

Re: Funcube Dongle Pro Plus help

Vincenzo,

please don't open a new thread for every other email you have sent. You
have gotten easily confused in the past, and we can avoid that if you
can try to focus on staying on a single email thread, and it was a big
problem for you. Please don't open a new thread before having solved
this issue, and instead reply to the things here, keeping
discuss-gnuradio@gnu.org in CC:.

Something went wrong during your software build or installation. We
can't tell you what that was - have you checked whether the cmake, the
make, the make install commands were successful?

Best regards,

Marcus

On 8/31/20 5:09 PM, Vincenzo Mone wrote:
>
> Hello
>
> Please I am trying to install the FCDPROPLUS which is the Funcube
> Dongle Pro Plus.
>
> This is what I've done following the instructions on the author page:
>
> git clone https://github.com/dl1ksv/gr-fcdproplus
>
> cd ~/gr-fcdproplus
>
> mkdir build
>
> cd build
>
> cmake -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE=Release ../
>
> make
>
> sudo make install
>
> sudo ldconfig
>
> then I have created a file named '99-usb-serial.rules' with the
> following content:
>
> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb56"
> MODE:="0666"
>
> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb31"
> MODE:="0666"
>
> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
> ATTRS{idProduct}=="fb56", MODE="0666"
>
> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
> ATTRS{idProduct}=="fb
>
> Then:
>
> cd /etc/udev/rules.d
>
> sudo cp -v ~/<your folder>/99-usb-serial.rules ./
>
> sudo udevadm trigger
>
> After that executing grc I sould find in Fcd
>
> Funcube Dongle
>
> Funcube Dongle control
>
> Funcube Dongle Pro+
>
> Funcube Dongle Pro+ control
>
> But I do not find any FCD group.
>
> Please anybody can tell me if I am doing something wrong?
>
> Thanks
>
> 73's de Enzo IK8OZV
> EasyLog 5 BetaTester
> EasyLog PDA BetaTester
> WinBollet BetaTester
> D.C.I. CheckPoint Regione Campania
> Skype: ik8ozv8520
>
>
>
>
> *********************************
>
> ****** GSM +39 328 7110193 ******
>
> ***** SMS +39 328 7110193 *****
>
> *********************************
>

Re: Using forgotten id breaks gnuradio-companion

On Mon, Aug 31, 2020 at 8:11 AM Jeff Long <willcode4@gmail.com> wrote:

Since there is no way of knowing what global names will conflict in the future, it could be useful for GRC to prefix ids (id_audio), make them part of another structure (ids.audio), or something similar. This adds complexity to manual coding in Python, so it's a tradeoff.

It would be sufficient to modify the constructor code generation so that variables aren't used — to use a non-conflicting example from a random generated .py file I have,

self.samp_rate = samp_rate = 44100

...

self.audio_sink_0 = audio.sink(samp_rate, "", True)

would be instead generated without a local variable as

self.samp_rate = 44100

...

self.audio_sink_0 = audio.sink(self.samp_rate, "", True)

If another case arises where that's not sufficient, I think it would still be a better idea to have GRC detect and alter Python variable names (or, possibly preferably, the names of module imports) on a case-by-case basis to avoid worsening readability (and edit distance from hand-maintained GR code).

Funcube Dongle Pro Plus help

Hello

Please I am trying to install the FCDPROPLUS which is the Funcube Dongle Pro Plus.

This is what I’ve done following the instructions on the author page:

git clone https://github.com/dl1ksv/gr-fcdproplus

cd ~/gr-fcdproplus

mkdir build

cd build

cmake -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE=Release ../

make

sudo make install

sudo ldconfig

then I have created a file named '99-usb-serial.rules' with the following content:

SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb56" MODE:="0666"

SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb31" MODE:="0666"

KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb56", MODE="0666"

KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb

Then:

cd /etc/udev/rules.d

sudo cp -v ~/<your folder>/99-usb-serial.rules ./

sudo udevadm trigger

After that executing grc I sould find in Fcd

Funcube Dongle

Funcube Dongle control

Funcube Dongle Pro+

Funcube Dongle Pro+ control

But I do not find any FCD group.

Please anybody can tell me if I am doing something wrong?

Thanks

73’s de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520

*********************************

****** GSM +39 328 7110193 ******

***** SMS +39 328 7110193 *****

*********************************

Re: Using forgotten id breaks gnuradio-companion

Since there is no way of knowing what global names will conflict in the future, it could be useful for GRC to prefix ids (id_audio), make them part of another structure (ids.audio), or something similar. This adds complexity to manual coding in Python, so it's a tradeoff.

On Mon, Aug 31, 2020 at 10:53 AM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

One of my flowgraph was generating the error:

self.audio_sink_0 = audio.sink(audio_rate, '', True)
AttributeError: 'int' object has no attribute 'sink'

This error was not easy to debug since the error message sounds like
there was a library error (which was not the case here).

My mistake was a "QT GUI Chooser" whose id was (incorrectly) set to
audio; "audio" being also the name of a gnuradio python module.

Now that I found my mistake, it's obvious that no ID should be set to
some python module name.

May be it could be interesting that gnuradio-companion tests block ids
and rejects forbidden ones when compiling flowgraph.

Regards

Using forgotten id breaks gnuradio-companion

Hi

One of my flowgraph was generating the error:

self.audio_sink_0 = audio.sink(audio_rate, '', True)
AttributeError: 'int' object has no attribute 'sink'

This error was not easy to debug since the error message sounds like
there was a library error (which was not the case here).

My mistake was a "QT GUI Chooser" whose id was (incorrectly) set to
audio; "audio" being also the name of a gnuradio python module.

Now that I found my mistake, it's obvious that no ID should be set to
some python module name.

May be it could be interesting that gnuradio-companion tests block ids
and rejects forbidden ones when compiling flowgraph.

Regards

Re: Ho to use Limesdr and rtl dongles with GNURadio 3.8.2

Thanks Paul

This in fact is an important information.

To resume I found that following packages installed from source under Ubuntu 20.04 (compiling some of them is tricky) are fully functionnal with GNURadio 3.8.2:

librtlsdr
gr-osmosdr
gr-limesdr (LimeSuite can be installed from ubuntu repository)
gqrx (if you want both GNU Radio AND gqrx)
gr-rds

For all these packages, installing from existing PPA (ubuntu and myriadrf repositories) breaks GNU Radio.

Regards

On 27/08/2020 12:44, Paul Boven wrote:

Hi Christophe,

This is unfortunately a known problem. The way GNU Radio was packaged in Ubuntu 20.04 is (to me) a bit odd, with the version number as part of the package name for most of the libraries.

If you install GR from the PPA, you will now get version 3.8.2, which is great. This will also include all the libraries. But if you then try to install a package from the regular Ubuntu repository, e.g. gr-osmosdr, this will pull in gnuradio-3.8.1 libraries. So now you end up with two versions of the gnuradio libraries installed on your system. Your gr-osmosdr (from the Ubuntu repositories) is linked against the 3.8.1 versions of the libraries, whereas the gnuradio on your system links against the 3.8.2 version of the libraries. Then, when you try to use the two together, mayhem ensues.

The result of this, is that the 3.8.2 on the PPA only works with itself, but not with the other packages from the regular Ubuntu LTS release. Unfortunately, the PPA is simply broken at this time.

Fixing this is not easy, because to solve the root cause, we'd have to figure out how to properly package GR for Ubuntu, and then convince Ubuntu to upgrade the version of GNU Radio (and all dependent packages!) that are part of the stable release.

Regards, Paul Boven.

On 8/27/20 12:25 PM, Christophe Seguinot wrote:

Hi

I recently switched my computer to Ubuntu 20.04 and installed GNURadio 3.8.2.0 from ppa (http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu). Version 3.8.2 is the latest in this PPA and is installed by default.

I also installed gr-osmosdr gr-limesdr and gr-rds using sudo apt install.

Gnuradio is running fine in most cases. However, each time I run a flowgraph involving SDR or LimeSDR Dongle I get the classical error:

     File "/home/-----/rds_rx.py", line 571, in __init__
         self.audio_sink_1 = audio.sink(audio_rate, '', True)
     AttributeError: 'int' object has no attribute 'sink'

Looking into library folder /usr/lib/x86_64-linux-gnu I found that some 3.8.1.1 and 3.8.0 libraries are installed and probably conflicting with 3.8.2.0 libraries. For example, command/ll libgnuradio-runtime*/ gives

     lrwxrwxrwx 1 root root      28 aug. 22 14:29 libgnuradio-runtime.so -> libgnuradio-runtime.so.3.8.2
     lrwxrwxrwx 1 root root      30 juil. 31 15:23 libgnuradio-runtime.so.3.8.1 -> libgnuradio-runtime.so.3.8.1.0
     -rw-r--r-- 1 root root 1077632 juil. 31 15:23 libgnuradio-runtime.so.3.8.1.0
     lrwxrwxrwx 1 root root      30 aug. 22 14:29 libgnuradio-runtime.so.3.8.2 -> libgnuradio-runtime.so.3.8.2.0
     -rw-r--r-- 1 root root 1077632 aug. 22 14:29 libgnuradio-runtime.so.3.8.2.0

It looks like 3.8.1 and 3.8.0 libraries have been installed when installing gr-osmosdr gr-limesdr and gr-rds

     installed libraries during gr-osmosdr install

         libgnuradio-audio.so.3.8.1

         libgnuradio-blocks.so.3.8.1

         libgnuradio-pmt.so.3.8.1

         libgnuradio-runtime.so.3.8.1

         libgnuradio-fcdproplus.so.3.8.0

         libgnuradio-iqbalance.so.3.8.0

         ilbgnuradio-uhd.so.3.8.0

         ibgnuradio-fosphor.so.3.8.0

     installed libraries during gr-rds install

         libgnuradio-analog.so.3.8.1

         libgnuradio-digital.so.3.8.1

         libgnuradio-filter.so.3.8.1

I also notice that gr-osmosdr and gr-limesdr depend on libgnuradio-xxx >= 3.8.1.0~rc1. So I don't understand why 3.8.1 libraries have been installed after 3.8.2 libraries

Here are my questions:

* Is the existence of these multiple libraries versions the cause of
    errors?
* Could someone please provide some link to PPA or source to compile
    (for gr-osmosdr and gr-limesdr) which are compatible with GNURadio
    3.8.2.0?
* Should I reverse to GNURadio 3.8.1 using PPA
    http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu?

Regards, Christophe

Re: Any Help Please?

That block is part of the gr-fcdproplus out-of-tree module. After you install that module, the GRC should be valid.

On Mon, Aug 31, 2020 at 8:00 AM Vincenzo Mone <vimone@alice.it> wrote:

Hello all,
I ma having problems to run a grc file.
I get a red block and do not know how to solve:

Any advice please?

73's de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520

      *********************************
      ******   GSM +39 328 7110193 ******
      *****     SMS +39 328 7110193    *****
      *********************************

Any Help Please?

Hello all,

I ma having problems to run a grc file.

I get a red block and do not know how to solve:

Any advice please?

73’s de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520

*********************************

****** GSM +39 328 7110193 ******

***** SMS +39 328 7110193 *****

*********************************

Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks

David,

As far as I know, 3.15 is the long term support UHD release, and should be considered the most stable. 4.0 has not been officially released yet (looks like release candidate went out last week). If your research does not involve the newest features of GNU Radio, but you need a stable version, I'd recommend sticking with 3.8.2 - which it it sounds like you have successfully done from source. It looks like there are two variables in play here - how GR is installed, and the version of GR. You can also install GR 3.8 from the PPA (gnuradio-releases), and of course 3.9 from source. But if having installed 3.8 from source is working for you, that seems like a good path to go down. For gr-uhd to be installed, you have to install uhd (either from the package manager - 20.04 has 3.15.0.0-1build5, or from source) before compiling GR. Take a look at the CMake stdout for GR to see if there are any other dependencies or issues that would prevent gr-uhd from being installed.

Josh

On Sun, Aug 30, 2020 at 1:26 PM David Taylor (manx.net) <drtaylor@manx.net> wrote:

Josh,

Many thanks for your questions and apologies for the delay in replying.

From a clean 20.04 Ubuntu, I installed 3.9 using the package installer from the master branch.

$ sudo add-apt-repository ppa:gnuradio/gnuradio -master

There were no major issues with the GRC install, transfer of old 3.7 OOT blocks, their new python binding, libraries linkage or block import for that matter.

The 3.9 OOT porting guide proved, helpful with some additional and relevant information to be found in the 3.8 porting guide particularly on external libraries inclusion.

UHD 3.15.0.0-2build5 from a package manager install works fine.

PYTHONPATH =/usr/local/lib/python3/dist-packages.

The OOT blocks are being installed to: /usr/local/lib/python3/dist-packages/test and the blocks to: /usr/local/share/gnuradio/grc/blocks

In all other respects the GRC works fine..

---------

Noting this release last weekend, on a separate drive, with a clean 20.04 Ubuntu, I have installed and built GRC 3.8.2.0 from gnuradio-3.8.2.0.tar.gz

OOT blocks import without issue as per 3.7.11 using the older SWIG bindings. VOLKGNSSSDR as an external library is both visible and useable.

I noticed that during the build the UHD interface was disabled and consequently the GRC source and sink blocks are both missing. These are available for build under ~/gr-uhd.

Is there a reason for this please?

Is 3.15 compatible and stable as a UHD interface, noting the very recent emergence of 4.0 RC?

My research in the first instance, is to investigate the intrinsic carrier phase stability of an SDR system in RF loop-back and then through a geo-stationary satellite.

The OOT blocks in development are of flexible direct spread spectrum coding and reception type.

It's therefore important that I settle on stable GRC/UHD variants for the next twelve months or so.

Best regards,

David GD4FMB

From: Josh

Sent: Monday, August 24, 2020 8:09 PM

To: David Taylor (manx.net)

Cc: GNURadio Discussion List

Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks

David,

1) How is your GNU Radio installed in this system?

2) It sounds a lot like PYTHONPATH is misconfigured for OOT - where are your OOT files being installed to?

Thanks,

Josh

On Fri, Aug 21, 2020 at 12:23 PM David Taylor (manx.net) <drtaylor@manx.net> wrote:

Josh,

Sorry to go over old ground yet again.

In order to remove any additional problems caused by the use of external libraries, I have created a separate OOT branch that is void of external libraries.

Stripped to the bone python and C++ blocks have been created using gr_modtool. Test codes validate the blocks code content as functional and they import correctly into the GRC with simple .yml.

The top level CMakeLists.txt and others are unmodified from a clean new module.

The current issue has been traced so far to the __init__.py file and its inability to resolve '__path__'

Consequently the pybind11 link fails to find my 'test' directory and the subsequent imported python block fails with no known parent package.

I am unclear how and where this is initialised under python3? I have attended to the usual library and path ~./bashrc changes to no avail.

The GRC outputs the AttributeError: message for the python and C++ OOT block.

Once resolved, I can move forward again with the external library inclusion.

Many thanks,

David GD4FMB

From: Josh

Sent: Monday, August 17, 2020 11:45 AM

To: David Taylor (manx.net)

Cc: GNURadio Discussion List

Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks

David,

I've found most of the time I get the "No module named ..." error it is due to C++ linkage issues in setting up the CMake. There was a big jump in CMake modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from 3.9) to create a new module and copy your blocks in from there is usually the easiest way. Porting guide is here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide and here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide

the one that usually gets me and causes the ModuleNotFoundError is this

https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components

Does your library reference any GR modules, or any other external libraries?

Josh

On Mon, Aug 17, 2020 at 3:58 AM David Taylor (manx.net) <drtaylor@manx.net> wrote:

Hi,

I have been developing a number of direct spread spectrum OOT blocks as part of a research project.

Working blocks were originally developed using GRC 3.7.11, however I wish to move forward and have installed and persevered so far with GRC 3.9 from the master branch.

The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been installed and build correctly.

I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the build process checking, have included a simple python OOT.

The C++ to python code binding, make and install under Ubuntu 20.04 all work and the new blocks import correctly to flow-graph using modified .yml descriptors.

1). GRC 9.0 works standalone from git-master install and with the UHD, in my case a B210.

2). OOT blocks including the aforementioned python OOT block all fail at import. In my case ModuleNotFoundError: No module named 'development'

i.e. failure of 'import development' in the flow-graph python script

3). I have tried and retained the library workarounds with PYTHONPATH and LD_LIBRARY_PATH, but these now seem irrelevant as the GRC basically loads and runs.

4). I have looked at the gr_modtool __init_.py file for indicators as to why both python and C++ blocks (using python bindings) both fail.

The inability of python 3.8.2 in my case to resolve the import is clearly at its core.

5). The OOT GRC blocks themselves import correctly into the flow-graph produce error free python script and all have relatively primitive interfaces.

Many thanks,

David Taylor

Sunday, August 30, 2020

Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks

Josh,

Many thanks for your questions and apologies for the delay in replying.

From a clean 20.04 Ubuntu, I installed 3.9 using the package installer from the master branch.

$ sudo add-apt-repository ppa:gnuradio/gnuradio -master

There were no major issues with the GRC install, transfer of old 3.7 OOT blocks, their new python binding, libraries linkage or block import for that matter.

The 3.9 OOT porting guide proved, helpful with some additional and relevant information to be found in the 3.8 porting guide particularly on external libraries inclusion.

UHD 3.15.0.0-2build5 from a package manager install works fine.

PYTHONPATH =/usr/local/lib/python3/dist-packages.

The OOT blocks are being installed to: /usr/local/lib/python3/dist-packages/test and the blocks to: /usr/local/share/gnuradio/grc/blocks

In all other respects the GRC works fine..

---------

Noting this release last weekend, on a separate drive, with a clean 20.04 Ubuntu, I have installed and built GRC 3.8.2.0 from gnuradio-3.8.2.0.tar.gz

OOT blocks import without issue as per 3.7.11 using the older SWIG bindings. VOLKGNSSSDR as an external library is both visible and useable.

I noticed that during the build the UHD interface was disabled and consequently the GRC source and sink blocks are both missing. These are available for build under ~/gr-uhd.

Is there a reason for this please?

Is 3.15 compatible and stable as a UHD interface, noting the very recent emergence of 4.0 RC?

My research in the first instance, is to investigate the intrinsic carrier phase stability of an SDR system in RF loop-back and then through a geo-stationary satellite.

The OOT blocks in development are of flexible direct spread spectrum coding and reception type.

It's therefore important that I settle on stable GRC/UHD variants for the next twelve months or so.

Best regards,

David GD4FMB

From: Josh

Sent: Monday, August 24, 2020 8:09 PM

To: David Taylor (manx.net)

Cc: GNURadio Discussion List

Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks

David,

1) How is your GNU Radio installed in this system?

2) It sounds a lot like PYTHONPATH is misconfigured for OOT - where are your OOT files being installed to?

Thanks,

Josh

On Fri, Aug 21, 2020 at 12:23 PM David Taylor (manx.net) <drtaylor@manx.net> wrote:

Josh,

Sorry to go over old ground yet again.

In order to remove any additional problems caused by the use of external libraries, I have created a separate OOT branch that is void of external libraries.

Stripped to the bone python and C++ blocks have been created using gr_modtool. Test codes validate the blocks code content as functional and they import correctly into the GRC with simple .yml.

The top level CMakeLists.txt and others are unmodified from a clean new module.

The current issue has been traced so far to the __init__.py file and its inability to resolve '__path__'

Consequently the pybind11 link fails to find my 'test' directory and the subsequent imported python block fails with no known parent package.

I am unclear how and where this is initialised under python3? I have attended to the usual library and path ~./bashrc changes to no avail.

The GRC outputs the AttributeError: message for the python and C++ OOT block.

Once resolved, I can move forward again with the external library inclusion.

Many thanks,

David GD4FMB

From: Josh

Sent: Monday, August 17, 2020 11:45 AM

To: David Taylor (manx.net)

Cc: GNURadio Discussion List

Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks

David,

I've found most of the time I get the "No module named ..." error it is due to C++ linkage issues in setting up the CMake. There was a big jump in CMake modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from 3.9) to create a new module and copy your blocks in from there is usually the easiest way. Porting guide is here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide and here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide

the one that usually gets me and causes the ModuleNotFoundError is this

https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components

Does your library reference any GR modules, or any other external libraries?

Josh

On Mon, Aug 17, 2020 at 3:58 AM David Taylor (manx.net) <drtaylor@manx.net> wrote:

Hi,

I have been developing a number of direct spread spectrum OOT blocks as part of a research project.

Working blocks were originally developed using GRC 3.7.11, however I wish to move forward and have installed and persevered so far with GRC 3.9 from the master branch.

The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been installed and build correctly.

I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the build process checking, have included a simple python OOT.

The C++ to python code binding, make and install under Ubuntu 20.04 all work and the new blocks import correctly to flow-graph using modified .yml descriptors.

1). GRC 9.0 works standalone from git-master install and with the UHD, in my case a B210.

2). OOT blocks including the aforementioned python OOT block all fail at import. In my case ModuleNotFoundError: No module named 'development'

i.e. failure of 'import development' in the flow-graph python script

3). I have tried and retained the library workarounds with PYTHONPATH and LD_LIBRARY_PATH, but these now seem irrelevant as the GRC basically loads and runs.

4). I have looked at the gr_modtool __init_.py file for indicators as to why both python and C++ blocks (using python bindings) both fail.

The inability of python 3.8.2 in my case to resolve the import is clearly at its core.

5). The OOT GRC blocks themselves import correctly into the flow-graph produce error free python script and all have relatively primitive interfaces.

Many thanks,

David Taylor

Saturday, August 29, 2020

Import Error with Custom Block

Hello GR community,

I am getting familiarized with creating my own out of tree modules and custom blocks however I seem to be having execution issues.

To start, I am trying to replicate one of the gr-adsb blocks (decoder) within my custom module, then append some modifications once it's been copied.

So far, I have created my own oot module and added the decoder block with the following lines:

gr_modtool newmod adsb_mods

gr_modtool add adsb_decoder_mod

I then copy the original decoder python code into adsb_decoder_mod.py and do the same with the original decoder xml code. The module builds without issue.

When I attempt to run the GR flowgraph with adsb_decoder_mod inside of it, I get the following error:

___________________________

Generating: '/home/cci5g2/tcas/top_block.py'

>>> Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion.

Executing: /usr/bin/python -u /home/cci5g2/tcas/top_block.py

Traceback (most recent call last):

File "/home/cci5g2/tcas/top_block.py", line 27, in <module>

import adsb_mods

File "/usr/local/lib/python2.7/dist-packages/adsb_mods/__init__.py", line 34, in <module>

from adsb_decoder_mod import adsb_decoder_mod

ImportError: cannot import name adsb_decoder_mod

___________________________

I have tried changing the executable directory in the cmake command however the error persists. What am I missing?

Thanks very much,

Adam

Friday, August 28, 2020

GSoC 2020: gr-dpd - Final week Blogpost & Project Summary

Hello everyone,

I have posted the final week blogpost consisting of this week's work and a Project summary of my GSoC project. Here is the link.

Final week's work highlights are as follows:

* Synchronised passing of 'taps' (manually commited changes from synchronisation_test branch).

* Added Data files in examples folder.

* Eliminate bug in predistorter & GMP model.

* Added Static_Predistorter_iq_data_file test flowgraph.

* Added RLS_iq_test flowgraph.

I express my gratitude towards the GNU Radio community for having me as a GSoC student developer and helping me throughout my journey of the project and successful conclusion of the summer project work.

Thank you!

Regards,

Alekh Gupta

Re: adalm-pluto gr-iio/iio-examples

Opps ! I have 2 different branches for gr-iio because one is the 3.7
branch for my odroids. So there is a significance difference between
the 2 branches :).

-- Cinaed

On 8/27/20 1:16 PM, Cinaed Simson wrote:
> Hi Derek - thanks, I already replaced them.
>
> Actually, I have 2 different versions - an Oct 2019 commit under my
> github area
>
> Author: Michael Hennerich <michael.hennerich@analog.com>
> Date: Tue Oct 29 08:08:14 2019 +0100
>
> and a Jun 2019 commit under my gnuradio build area
>
> Author: AlexandraTrifan <Alexandra.Trifan@analog.com>
> Date: Thu Jun 4 10:15:35 2020 +0300
>
> When I did a git pull on the June version prior to building the
> gr-iio, it claimed it was up already up to date.
>
> The 2 different commits are still claiming they're both up to date.
>
> I'm not sure if the difference is significant - I may play with them
> later.
>
> I have the WBFM working now - it was a firmware issue.
>
> -- Cinaed
>
> On 8/27/20 1:12 AM, Derek Kozel wrote:
>> That's a issue with gr-iio's grc yaml files if that's the case. There
>> are a few forks of gr-iio around at the moment, something that's very
>> close to being permanently fixed. You should be able to find a
>> iio_pluto_sink.block.yml file that will make the Pluto Sink block
>> appear in GRC. Possibly the version you've installed is missing it,
>> or it's not been installed in the right place.
>>
>> https://github.com/analogdevicesinc/gr-iio/tree/cmake-update-3.8/grc
>>
>> On 27/08/2020 05:33, Cinaed Simson wrote:
>>> You're right - great - thanks!
>>>
>>> But it's misses the PlutoSDR sinks and sources - they show up as
>>> missing blocks.
>>>
>>> -- Cinaed
>>>
>>> On 8/22/20 9:20 AM, Derek Kozel wrote:
>>>> In most cases the examples should update automatically when opened
>>>> in GNU Radio 3.8.
>>>>
>>>> On 8/21/2020 10:52 PM, Cinaed Simson wrote:
>>>>> Has anyone converted or ported the GRC example files in
>>>>> gr-iio/iio-examples for gnuradio-3.8?
>>>>>
>>>>> I checkout the version of gr-iio for gnuradio-3.8 but example GRC
>>>>> files in gr-iio/iio-examples are XML files - or for 3.7.
>>>>>
>>>>> -- Cinaed
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

Re: Discuss-gnuradio Digest, Vol 214, Issue 29

On Fri, Aug 28, 2020, 00:03 <discuss-gnuradio-request@gnu.org> wrote:

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

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

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

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

Today's Topics:

1. How to toggle between two different file paths in File Source
(Jonathan Morales)
2. Re: How to toggle between two different file paths in File
Source (Jeff Long)
3. linux distro with GNU Radio preinstalled? (Kristoff)
4. Re: linux distro with GNU Radio preinstalled? (Sid Hayn)
5. BPSK tutorial (Barry Duggan)
6. Re: adalm-pluto gr-iio/iio-examples (Cinaed Simson)
7. Re: linux distro with GNU Radio preinstalled? (Derek Kozel)
8. Re: adalm-pluto gr-iio/iio-examples (Derek Kozel)
9. Ho to use Limesdr and rtl dongles with GNURadio 3.8.2
(Christophe Seguinot)
10. Re: Ho to use Limesdr and rtl dongles with GNURadio 3.8.2
(Paul Boven)
11. Re: [USRP-users] GPIO setup via gnuradio (Ivan Zahartchuk)
12. Re: linux distro with GNU Radio preinstalled? (Kristoff)
13. Re: BPSK tutorial (Barry Duggan)

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

Message: 1
Date: Wed, 26 Aug 2020 17:39:06 -0400
From: Jonathan Morales <jonathan.morales100@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: How to toggle between two different file paths in File Source
Message-ID:
<CAKQU3jPKtBcgehJZW3VcCaB5g8ZL6Nfcf2cqDf9t=jwzwPJM7A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello!

I've been struggling to figure out how to send one file, delay, then switch
to sending a second different file. I've been using gnuradio-companion to
generate a Python script which I manipulate. I've tried resetting the
filepath call after a delay but, when I run the script it continues to
only send the first file.

Regards,
J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200826/df8e1cb0/attachment.html>

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

Message: 2
Date: Wed, 26 Aug 2020 18:16:01 -0400
From: Jeff Long <willcode4@gmail.com>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: Re: How to toggle between two different file paths in File
Source
Message-ID:
<CAC5f9jbXDTUeBrDYKxW80gUiRKCJ5gnMm-2pjAa064EqO4CDeA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Try calling src.open(filename, repeat) after the delay.

On Wed, Aug 26, 2020 at 5:41 PM Jonathan Morales <
jonathan.morales100@gmail.com> wrote:

>
> Hello!
>
> I've been struggling to figure out how to send one file, delay, then
> switch to sending a second different file. I've been using
> gnuradio-companion to generate a Python script which I manipulate. I've
> tried resetting the filepath call after a delay but, when I run the script
> it continues to only send the first file.
>
> Regards,
> J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200826/c2363d62/attachment.html>

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

Message: 3
Date: Thu, 27 Aug 2020 00:21:14 +0200
From: Kristoff <kristoff@skypro.be>
To: "discuss-gnuradiognu.org" <discuss-gnuradio@gnu.org>
Subject: linux distro with GNU Radio preinstalled?
Message-ID: <3f0916c7-f94d-7065-e0af-6506734725a0@skypro.be>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi all,

I am giving an (online) presentation / demo of GNU Radio next week.

As I do not know if there will be a lot of linux-users, I would like to
provide an easy-to-use option for windows users.

The GNU Radio Live mentioned on the GNU Radio website (*) is based on
Ubuntu 2016.04, which is ... euh ... not very recent :-)
Are there any new linux distro / liveCDs that have GNU Radio
preinstalled and ready to use, either to boot from USB dongle or in a VM?

(*)
https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment

Kristoff (ON1ARF)

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

Message: 4
Date: Wed, 26 Aug 2020 20:54:07 -0400
From: Sid Hayn <sidhayn@gmail.com>
To: Kristoff <kristoff@skypro.be>
Cc: "discuss-gnuradiognu.org" <discuss-gnuradio@gnu.org>
Subject: Re: linux distro with GNU Radio preinstalled?
Message-ID:
<CAM0KTbBuKJXx1RBBOMxt_62KmcT_ZbPfYoSqXk9A6Zgk1GCW8g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

I am biased (my livecd) but Pentoo Linux has gnuradio and a few other
sdr programs pre-installed. I'm in the middle of prepping for a
release, so I can confirm that the daily isos are both very up to date
and reasonably bug free. The download page itself is a bit outdated
(it references an older release) but the dailies are from...today.
https://pentoo.ch/downloads

Feel free to email me off list or join my discord (linked on the above
site) if you are interested and care to discuss.

Thanks,
Zero

On Wed, Aug 26, 2020 at 6:22 PM Kristoff <kristoff@skypro.be> wrote:
>
> Hi all,
>
>
> I am giving an (online) presentation / demo of GNU Radio next week.
>
>
> As I do not know if there will be a lot of linux-users, I would like to
> provide an easy-to-use option for windows users.
>
> The GNU Radio Live mentioned on the GNU Radio website (*) is based on
> Ubuntu 2016.04, which is ... euh ... not very recent :-)
> Are there any new linux distro / liveCDs that have GNU Radio
> preinstalled and ready to use, either to boot from USB dongle or in a VM?
>
>
> (*)
> https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment
>
>
> Kristoff (ON1ARF)
>
>
>
>
>

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

Message: 5
Date: Wed, 26 Aug 2020 19:57:53 -0500
From: Barry Duggan <barry@dcsmail.net>
To: Discuss Gnuradio <discuss-gnuradio@gnu.org>
Subject: BPSK tutorial
Message-ID: <60092d7c-a33a-3893-767d-36d1d2cc03bc@dcsmail.net>
Content-Type: text/plain; charset=utf-8; format=flowed

For those of you who have been asking questions about BPSK, I have
created
https://wiki.gnuradio.org/index.php/Simulation_example:_BPSK_Demodulation,
which is a follow-on to the QPSK tutorial. Questions and comments are
welcome!

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

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

Message: 6
Date: Wed, 26 Aug 2020 21:33:39 -0700
From: Cinaed Simson <cinaed.simson@gmail.com>
To: discuss-gnuradio@gnu.org
Subject: Re: adalm-pluto gr-iio/iio-examples
Message-ID: <0f71eb6c-5a9e-e469-1bb6-3f3445eea836@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

You're right - great - thanks!

But it's misses the PlutoSDR sinks and sources - they show up as missing
blocks.

-- Cinaed

On 8/22/20 9:20 AM, Derek Kozel wrote:
> In most cases the examples should update automatically when opened in
> GNU Radio 3.8.
>
> On 8/21/2020 10:52 PM, Cinaed Simson wrote:
>> Has anyone converted or ported the GRC example files in
>> gr-iio/iio-examples for gnuradio-3.8?
>>
>> I checkout the version of gr-iio for gnuradio-3.8 but example GRC
>> files in gr-iio/iio-examples are XML files - or for 3.7.
>>
>> -- Cinaed
>>
>
>

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

Message: 7
Date: Thu, 27 Aug 2020 08:57:11 +0100
From: Derek Kozel <derek@bitstovolts.com>
To: Kristoff <kristoff@skypro.be>, "discuss-gnuradiognu.org"
<discuss-gnuradio@gnu.org>
Subject: Re: linux distro with GNU Radio preinstalled?
Message-ID: <2305bdc4-0111-80c5-4626-46810fca6b9e@bitstovolts.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Kristoff,

There are a bunch of ones around which have GNU Radio pre-installed, but
my most common answer remains using the vanilla Ubuntu 20.04 live image
and installing GNU Radio and any needed OOT modules from the Software
library.

Clicking this link will open up the install page for GNU Radio

http://apt.ubuntu.com/p/gnuradio

The same works for many OOTs and apps like GQRX.

http://apt.ubuntu.com/p/gr-iio

Cheers,
Derek

On 26/08/2020 23:21, Kristoff wrote:
> Hi all,
>
>
> I am giving an (online) presentation / demo of GNU Radio next week.
>
>
> As I do not know if there will be a lot of linux-users, I would like
> to provide an easy-to-use option for windows users.
>
> The GNU Radio Live mentioned on the GNU Radio website (*) is based on
> Ubuntu 2016.04, which is ... euh ... not very recent :-)
> Are there any new linux distro / liveCDs that have GNU Radio
> preinstalled and ready to use, either to boot from USB dongle or in a VM?
>
>
> (*)
> https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment
>
>
> Kristoff (ON1ARF)
>
>
>
>
>

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

Message: 8
Date: Thu, 27 Aug 2020 09:12:08 +0100
From: Derek Kozel <derek@bitstovolts.com>
To: Cinaed Simson <cinaed.simson@gmail.com>, discuss-gnuradio@gnu.org
Subject: Re: adalm-pluto gr-iio/iio-examples
Message-ID: <1ec743d2-a672-46a3-2266-479411ebfd5a@bitstovolts.com>
Content-Type: text/plain; charset=utf-8; format=flowed

That's a issue with gr-iio's grc yaml files if that's the case. There
are a few forks of gr-iio around at the moment, something that's very
close to being permanently fixed. You should be able to find a
iio_pluto_sink.block.yml file that will make the Pluto Sink block appear
in GRC. Possibly the version you've installed is missing it, or it's not
been installed in the right place.

https://github.com/analogdevicesinc/gr-iio/tree/cmake-update-3.8/grc

On 27/08/2020 05:33, Cinaed Simson wrote:
> You're right - great - thanks!
>
> But it's misses the PlutoSDR sinks and sources - they show up as
> missing blocks.
>
> -- Cinaed
>
> On 8/22/20 9:20 AM, Derek Kozel wrote:
>> In most cases the examples should update automatically when opened in
>> GNU Radio 3.8.
>>
>> On 8/21/2020 10:52 PM, Cinaed Simson wrote:
>>> Has anyone converted or ported the GRC example files in
>>> gr-iio/iio-examples for gnuradio-3.8?
>>>
>>> I checkout the version of gr-iio for gnuradio-3.8 but example GRC
>>> files in gr-iio/iio-examples are XML files - or for 3.7.
>>>
>>> -- Cinaed
>>>
>>
>>
>
>

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

Message: 9
Date: Thu, 27 Aug 2020 12:25:19 +0200
From: Christophe Seguinot <christophe.seguinot@orange.fr>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: Ho to use Limesdr and rtl dongles with GNURadio 3.8.2
Message-ID: <5102a075-64c0-139e-593d-91a24bff4a33@orange.fr>
Content-Type: text/plain; charset="utf-8"

An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200827/d566d0ad/attachment.html>

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

Message: 10
Date: Thu, 27 Aug 2020 12:44:36 +0200
From: Paul Boven <p.boven@xs4all.nl>
To: discuss-gnuradio@gnu.org
Subject: Re: Ho to use Limesdr and rtl dongles with GNURadio 3.8.2
Message-ID: <c63d6c5a-e4c4-c8dc-3b3e-15b8aa617636@xs4all.nl>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Christophe,

This is unfortunately a known problem. The way GNU Radio was packaged in
Ubuntu 20.04 is (to me) a bit odd, with the version number as part of
the package name for most of the libraries.

If you install GR from the PPA, you will now get version 3.8.2, which is
great. This will also include all the libraries. But if you then try to
install a package from the regular Ubuntu repository, e.g. gr-osmosdr,
this will pull in gnuradio-3.8.1 libraries. So now you end up with two
versions of the gnuradio libraries installed on your system. Your
gr-osmosdr (from the Ubuntu repositories) is linked against the 3.8.1
versions of the libraries, whereas the gnuradio on your system links
against the 3.8.2 version of the libraries. Then, when you try to use
the two together, mayhem ensues.

The result of this, is that the 3.8.2 on the PPA only works with itself,
but not with the other packages from the regular Ubuntu LTS release.
Unfortunately, the PPA is simply broken at this time.

Fixing this is not easy, because to solve the root cause, we'd have to
figure out how to properly package GR for Ubuntu, and then convince
Ubuntu to upgrade the version of GNU Radio (and all dependent packages!)
that are part of the stable release.

Regards, Paul Boven.

On 8/27/20 12:25 PM, Christophe Seguinot wrote:
> Hi
>
> I recently switched my computer to Ubuntu 20.04 and installed GNURadio
> 3.8.2.0 from ppa
> (http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu). Version
> 3.8.2 is the latest in this PPA and is installed by default.
>
> I also installed gr-osmosdr gr-limesdr and gr-rds using sudo apt install.
>
> Gnuradio is running fine in most cases. However, each time I run a
> flowgraph involving SDR or LimeSDR Dongle I get the classical error:
>
>     File "/home/-----/rds_rx.py", line 571, in __init__
>         self.audio_sink_1 = audio.sink(audio_rate, '', True)
>     AttributeError: 'int' object has no attribute 'sink'
>
> Looking into library folder /usr/lib/x86_64-linux-gnu I found that some
> 3.8.1.1 and 3.8.0 libraries are installed and probably conflicting with
> 3.8.2.0 libraries. For example, command/ll libgnuradio-runtime*/ gives
>
>     lrwxrwxrwx 1 root root      28 aug. 22 14:29
> libgnuradio-runtime.so -> libgnuradio-runtime.so.3.8.2
>     lrwxrwxrwx 1 root root      30 juil. 31 15:23
> libgnuradio-runtime.so.3.8.1 -> libgnuradio-runtime.so.3.8.1.0
>     -rw-r--r-- 1 root root 1077632 juil. 31 15:23
> libgnuradio-runtime.so.3.8.1.0
>     lrwxrwxrwx 1 root root      30 aug. 22 14:29
> libgnuradio-runtime.so.3.8.2 -> libgnuradio-runtime.so.3.8.2.0
>     -rw-r--r-- 1 root root 1077632 aug. 22 14:29
> libgnuradio-runtime.so.3.8.2.0
>
> It looks like 3.8.1 and 3.8.0 libraries have been installed when
> installing gr-osmosdr gr-limesdr and gr-rds
>
>     installed libraries during gr-osmosdr install
>
>         libgnuradio-audio.so.3.8.1
>
>         libgnuradio-blocks.so.3.8.1
>
>         libgnuradio-pmt.so.3.8.1
>
>         libgnuradio-runtime.so.3.8.1
>
>         libgnuradio-fcdproplus.so.3.8.0
>
>         libgnuradio-iqbalance.so.3.8.0
>
>         ilbgnuradio-uhd.so.3.8.0
>
>         ibgnuradio-fosphor.so.3.8.0
>
>     installed libraries during gr-rds install
>
>         libgnuradio-analog.so.3.8.1
>
>         libgnuradio-digital.so.3.8.1
>
>         libgnuradio-filter.so.3.8.1
>
>
> I also notice that gr-osmosdr and gr-limesdr depend on libgnuradio-xxx
> >= 3.8.1.0~rc1. So I don't understand why 3.8.1 libraries have been
> installed after 3.8.2 libraries
>
> Here are my questions:
>
> * Is the existence of these multiple libraries versions the cause of
> errors?
> * Could someone please provide some link to PPA or source to compile
> (for gr-osmosdr and gr-limesdr) which are compatible with GNURadio
> 3.8.2.0?
> * Should I reverse to GNURadio 3.8.1 using PPA
> http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu?
>
>
>
> Regards, Christophe
>
>

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

Message: 11
Date: Thu, 27 Aug 2020 15:20:10 +0300
From: Ivan Zahartchuk <adray0001@gmail.com>
To: Michael Dickens <michael.dickens@ettus.com>, usrp-users
<usrp-users@lists.ettus.com>, discuss-gnuradio
<discuss-gnuradio@gnu.org>
Subject: Re: [USRP-users] GPIO setup via gnuradio
Message-ID:
<CAPRRyxtyuiCF4ikKZsz8T-gNSmfWC0BBEgVA6ypEEEbN=2Y-4g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi there. My problem is that even after calibration I can clearly see the
mirror channel on my USRP N 210 with SBX. Maybe someone will tell you how
to solve this problem. This problem is observed on several boards and
different boards.

вт, 16 июн. 2020 г. в 17:28, Michael Dickens <michael.dickens@ettus.com>:

> Hi Ivan - OK; so you got the GRC <-> GR <-> UHD <-> GPIO access to work?
> Well done!
>
> As for your next question about tuning times: the E313 is the same as an
> E310 in terms of the USRP part. Here's my understanding:
>
> Tuning times if the frequencies do not require changing out a RX filter
> should be around 25 ms; jumping between RX filters should be more like 125
> ms; we use a different "RX filter" for each different frequency range.
> These are -very- typical tuning times for the E31x series; actually, this
> is true for most of our USRPs except the N3xy series which are
> intentionally designed with fast frequency switching in mind (among other
> attributes).
>
> In theory one could speed up tuning via FPGA code. I'm not an FPGA
> programmer, so I don't know how to do this nor the complexity of doing so
> -- just that in theory it could be done for specific user needs.
>
> I hope this is useful! - MLD
> ---
> Michael Dickens
> Ettus Research Technical Support
> Email: support@ettus.com
> Web: https://ettus.com/
>
>
> On Tue, Jun 16, 2020 at 6:39 AM Ivan Zahartchuk <adray0001@gmail.com>
> wrote:
>
>> Hello. I nevertheless got to work and equipment and everything worked
>> out for me. Gpio works. It turns out that in theory, you can connect to it
>> through dev as well as to the gps receiver. I have one more question for
>> you. I plan to also use the E313 as a frequency tunable scanning receiver.
>> But as far as I was written before (and I was convinced of this myself)
>> that the frequency tuning is slow due to the configuration of the filters
>> on the board. Tell me how can I get around this and speed up the scan. I
>> want to achieve a speed of at least 1ms at 50 MHz and the frequency tuning
>> itself in the E310 takes about 100 ms.
>>
>> пт, 29 мая 2020 г. в 23:28, Michael Dickens <michael.dickens@ettus.com>:
>>
>>> Hi Ivan - It was a crazy week for me; I still don't even have the
>>> required software installed; putting out so many fires I can't count them
>>> any longer! I sincerely hope next week is less stressful, and I can make
>>> progress on getting things installed. Have you made any progress on your
>>> end? Cheers & happy weekend again! - MLD
>>> ---
>>> Michael Dickens
>>> Ettus Research Technical Support
>>> Email: support@ettus.com
>>> Web: https://ettus.com/
>>>
>>>
>>> On Mon, May 25, 2020 at 6:36 PM Ivan Zahartchuk <adray0001@gmail.com>
>>> wrote:
>>>
>>>> Hello. There are no changes so far. There is no way to get to the
>>>> equipment. Waiting for your feedback on the code. Have a nice weekend))))
>>>>
>>>> вт, 19 мая 2020 г. в 00:19, Michael Dickens <michael.dickens@ettus.com
>>>> >:
>>>>
>>>>> HI Ivan - Happy Monday! I hope you had a good weekend. I took an extra
>>>>> part day off on both ends, which made for a lovely elongated time. I'll
>>>>> take a look at your code shortly; I'm moving between computers, so I'll
>>>>> need to create the UHD 3.15.0.0 + GR 3.7.14.0 Release + gr-ettus master
>>>>> installs for testing this. Always a good time getting a new computer, but
>>>>> it does take time to set it up reasonably well! Any updates on your end? -
>>>>> MLD
>>>>> ---
>>>>> Michael Dickens
>>>>> Ettus Research Technical Support
>>>>> Email: support@ettus.com
>>>>> Web: https://ettus.com/
>>>>>
>>>>>
>>>>> On Fri, May 15, 2020 at 9:46 AM Ivan Zahartchuk <adray0001@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks for your support. The archive has a file for USRP E310 and for
>>>>>> PC. For now, I'm just sending a request via gnuradio using the slider. I
>>>>>> just have not figured out get_gpio_attr but the fact that the values change
>>>>>> there gives me hope that this works.
>>>>>>
>>>>>> пт, 15 мая 2020 г. в 00:09, Michael Dickens <
>>>>>> michael.dickens@ettus.com>:
>>>>>>
>>>>>>> That's some positive progress, Ivan! Do you have any code you can
>>>>>>> pass on to me to try? I have a variety of USRPs around that should be
>>>>>>> usable with GPIO; doesn't need to be an E310 specifically (that's what my
>>>>>>> notes tell me you're using ... yes?). I also have both UHD 3.15.0.0 and the
>>>>>>> 3.15.LTS branch available for testing. - MLD
>>>>>>> ---
>>>>>>> Michael Dickens
>>>>>>> Ettus Research Technical Support
>>>>>>> Email: support@ettus.com
>>>>>>> Web: https://ettus.com/
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 14, 2020 at 3:50 PM Ivan Zahartchuk <adray0001@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello. Yes, I have advanced in this direction. Indeed, I figured out a bit with GPIO. The idea is to initialize usrp_source earlier than the RFNoC block (I don't know what this is related to), and then I avoid the error and in theory I have the same access to gpio. But when calling the get_gpio_banks command. "FP0" is returned to me and not "INTO"; I have not yet carried out any further experiments in connection with quarantine.
>>>>>>>>
>>>>>>>>
>>>>>>>> чт, 14 мая 2020 г. в 22:29, Michael Dickens <
>>>>>>>> michael.dickens@ettus.com>:
>>>>>>>>
>>>>>>>>> Hi Ivan - I'm glad to hear you got the firmware / FPGA images
>>>>>>>>> sorted out. That's really quite something! I'll need to do some playing
>>>>>>>>> around with how to do GPIO in UHD C++. I'm confident there's a way ... just
>>>>>>>>> need the right "special sauce" if you know what I mean. Maybe you've made
>>>>>>>>> progress on this end? - MLD
>>>>>>>>> ---
>>>>>>>>> Michael Dickens
>>>>>>>>> Ettus Research Technical Support
>>>>>>>>> Email: support@ettus.com
>>>>>>>>> Web: https://ettus.com/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, May 11, 2020 at 4:04 PM Ivan Zahartchuk <
>>>>>>>>> adray0001@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> If I understand you correctly, then I need to create another
>>>>>>>>>> block uhd
>>>>>>>>>> self.uhd_usrp_source = uhd.usrp_source ( ",". join (("",
>>>>>>>>>> "")), uhd.stream_args ( cpu_format = "fc32",
>>>>>>>>>> channels = range (1), ), )
>>>>>>>>>> so I created it. But I don't understand how it works since I
>>>>>>>>>> don't connect it anywhere and I get an error
>>>>>>>>>> [WARNING] [RFNOC] [legacy compat] Not enough FIFO ports to
>>>>>>>>>> connect, not all TX sinks will be connected [WARNING] [RFNOC]
>>>>>>>>>> [legacy_compat] No DDCs detected. You will only be able to receive at the
>>>>>>>>>> radio frontend rate. [WARNING] [RFNOC] [legacy_compat] No DUCs detected.
>>>>>>>>>> You will only be able to transmit at the radio frontend rate. [WARNING]
>>>>>>>>>> [RFNOC] Assuming max packet size for 0 / Radio_0 thread [thread-per-block
>>>>>>>>>> [0]: <block uhd_rfnoc_FIFO (7)>]: RuntimeError: On node 0 / FIFO_0, output
>>>>>>>>>> port 0 is already connected.
>>>>>>>>>> If somewhere there are examples of how to get to gpio correctly,
>>>>>>>>>> I would be very grateful if you would provide them to me. I figured out the
>>>>>>>>>> FPGA firmware and now the only problem is gpio.
>>>>>>>>>>
>>>>>>>>>> пн, 11 мая 2020 г. в 17:58, Michael Dickens <
>>>>>>>>>> michael.dickens@ettus.com>:
>>>>>>>>>>
>>>>>>>>>>> Hi Ivan - I was out last week; here now for a few days. Please
>>>>>>>>>>> keep support@ettus.com on CC so that someone there can try to
>>>>>>>>>>> help you when I'm away.
>>>>>>>>>>>
>>>>>>>>>>> Here's a summary of the discussion with the Ettus R&D person I
>>>>>>>>>>> spoke with about accessing the GPIO via GRC: you have to create a UHD USRP
>>>>>>>>>>> Source/Sink object, then you use it to access the underlying C++ USRP
>>>>>>>>>>> object (via Python) to obtain the GPIO API. You can't access the UHD GPIO
>>>>>>>>>>> API from RFNoC blocks; there is no USRP object to provide access.
>>>>>>>>>>>
>>>>>>>>>>> Are you still having issues with the FPGA creation? If so,
>>>>>>>>>>> please update me on where you're at and I'll do what I can to help. - MLD
>>>>>>>>>>> ---
>>>>>>>>>>> Michael Dickens
>>>>>>>>>>> Ettus Research Technical Support
>>>>>>>>>>> Email: support@ettus.com
>>>>>>>>>>> Web: https://ettus.com/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 7, 2020 at 7:38 AM Ivan Zahartchuk <
>>>>>>>>>>> adray0001@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello. Sorry to bother you so often. But I really want to
>>>>>>>>>>>> understand this board and firmware. I solved the problem with the fact that
>>>>>>>>>>>> I did not create an image for FPGA. The problem was that at startup, the
>>>>>>>>>>>> rfnoc_ce_auto_inst_e31x.v configuration file is created, which also tells
>>>>>>>>>>>> which blocks to compile for VIvado. But the next time you call
>>>>>>>>>>>> ./uhd_image_builder, this file is not replaced with a new one, but the
>>>>>>>>>>>> rfnoc_ce_auto_inst_e310.v file is created, which does not participate in
>>>>>>>>>>>> further work. But I also had questions about the GPIO.
>>>>>>>>>>>>
>>>>>>>>>>>> вс, 3 мая 2020 г. в 14:09, Ivan Zahartchuk <adray0001@gmail.com
>>>>>>>>>>>> >:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello. Your colleagues haven't answered anything yet? Tell me,
>>>>>>>>>>>>> could you generate firmware for RFNoC and drop it to me. Sorry to ask a
>>>>>>>>>>>>> lot, I just can not test the error with generating a bit file for FPGA
>>>>>>>>>>>>> differently.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ср, 29 апр. 2020 г. в 08:11, Ivan Zahartchuk <
>>>>>>>>>>>>> adray0001@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks! I found out that the problem in the firmware comes
>>>>>>>>>>>>>> from applications for creating this firmware. After opening the firmware
>>>>>>>>>>>>>> using Vivado, I found in it the same FIR block that I did not add there.
>>>>>>>>>>>>>> Perhaps this is due to the fact that I installed the wrong version of
>>>>>>>>>>>>>> Vivado. Because I also don't generate the dts file that is needed for
>>>>>>>>>>>>>> firmware. I installed Vivado 18.3 HL System Edition.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ср, 29 апр. 2020 г. в 00:12, Michael Dickens <
>>>>>>>>>>>>>> michael.dickens@ettus.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Ivan - Let me discuss your query with the Ettus R&D guy
>>>>>>>>>>>>>>> who handles gr-uhd. Hopefully he'll be able to clarify your query. - MLD
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> Michael Dickens
>>>>>>>>>>>>>>> Ettus Research Technical Support
>>>>>>>>>>>>>>> Email: support@ettus.com
>>>>>>>>>>>>>>> Web: https://ettus.com/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Apr 27, 2020 at 7:59 PM Ivan Zahartchuk <
>>>>>>>>>>>>>>> adray0001@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Unfortunately for all this time I have not come a step closer to solving my problems. I don't know how to solve the problem with flashing fpga.
>>>>>>>>>>>>>>>> I even reinstalled ubuntu but it did not help. The only assumption is that the board has its own memory that is not erased after overwriting the SD card. But this is also doubtful.
>>>>>>>>>>>>>>>> In addition, I still didn't get to switch to the GPIO through the RFNoC block and I am thinking about returning to version 3.14. But honestly I would like to deal with this version.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200827/d53bf6c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2020-08-27 15-11-36.png
Type: image/png
Size: 59660 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200827/d53bf6c6/attachment.png>

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

Message: 12
Date: Thu, 27 Aug 2020 15:08:23 +0200
From: Kristoff <kristoff@skypro.be>
To: Derek Kozel <derek@bitstovolts.com>, "discuss-gnuradiognu.org"
<discuss-gnuradio@gnu.org>
Subject: Re: linux distro with GNU Radio preinstalled?
Message-ID: <4fbe6b3f-6861-f43f-d795-144f5e46c337@skypro.be>
Content-Type: text/plain; charset=utf-8; format=flowed

Derek, Sid,

Sid,

Thanks. Looks like a good starting-point. thx :-)

Derek,

That is true, but I want to focus the workshop in GNU Radio itself, not
on how-to-install-GNU-Radio :-)

So I prefer something where everything is already pre-installed and that
the user just needs to do two things: 1/ configure his/her keyboard, 2/
"click on the GNU Radio Companion icon on your desktop".
Most of these people (with a few exceptions) are complete new to both
GNU Radio and linux, and I do not want to scare them away by demanding
they also need to learn linux.

BTW.
Somebody replied offlist mentioning sigintos. That's also an interesting
option.
(I do know one of the people who wants to learn GNU Radio for cybersecurity)

Kristoff

On 27/08/2020 09:57, Derek Kozel wrote:
> Hi Kristoff,
>
> There are a bunch of ones around which have GNU Radio pre-installed,
> but my most common answer remains using the vanilla Ubuntu 20.04 live
> image and installing GNU Radio and any needed OOT modules from the
> Software library.
>
> Clicking this link will open up the install page for GNU Radio
>
> http://apt.ubuntu.com/p/gnuradio
>
> The same works for many OOTs and apps like GQRX.
>
> http://apt.ubuntu.com/p/gr-iio
>
> Cheers,
> Derek
>
> On 26/08/2020 23:21, Kristoff wrote:
>> Hi all,
>>
>>
>> I am giving an (online) presentation / demo of GNU Radio next week.
>>
>>
>> As I do not know if there will be a lot of linux-users, I would like
>> to provide an easy-to-use option for windows users.
>>
>> The GNU Radio Live mentioned on the GNU Radio website (*) is based on
>> Ubuntu 2016.04, which is ... euh ... not very recent :-)
>> Are there any new linux distro / liveCDs that have GNU Radio
>> preinstalled and ready to use, either to boot from USB dongle or in a
>> VM?
>>
>>
>> (*)
>> https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment
>>
>>
>> Kristoff (ON1ARF)
>>
>>
>>
>>
>>
>

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

Message: 13
Date: Thu, 27 Aug 2020 09:04:57 -0500
From: Barry Duggan <barry@dcsmail.net>
To: Javier Acevedo <jracevedob@gmail.com>
Cc: Discuss Gnuradio <discuss-gnuradio@gnu.org>
Subject: Re: BPSK tutorial
Message-ID: <280b696b-6b10-efbe-507f-bc4d8f8873fe@dcsmail.net>
Content-Type: text/plain; charset=utf-8; format=flowed

Javier,

It can be very confusing! First, you need to work through every step of
the https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
(QPSK) tutorial. It uses 2 bit symbols and 4 samples per symbol.

The BPSK tutorial uses 1 bit symbols and 4 samples per symbol. The
difference between QPSK and BPSK is the number of bits per symbol. In
both cases, the Constellation Modulator block uses all 8 input bits.
Note that the Constellation Object is different between QPSK and BPSK.

Then you need to build a new flowgraph for the
https://wiki.gnuradio.org/index.php/Simulation_example:_BPSK_Demodulation#Decoding

As you can see in the BPSK stage6 flowgraph, the CMA Equalizer is
optional under your conditions. I left it out of the BPSK to simplify
the flowgraph.

P.S. Please Cc discuss-gnuradio@gnu.org in your responses so that it is
included in the discussion thread.
---
Barry Duggan KV4FV
https://github.com/duggabe

On 8/27/20 7:56 AM, Javier Acevedo wrote:
> Dear Barry,
>
> Currently I am implementing a BPSK transceiver using the USRP N310,
> which has a sample rate of 125MS/s. Nevertheless, I have some doubts
> about the parameters which I have to set in GNU Radio in order to have a
> stable transceiver. For example, in your simulation you set the input
> using a random source, which produces random numbers from 0 to 255. I
> know that GNU Radio splits each input byte into 4 samples of 2 bits.
> Then, you are setting as input values from 0 to 3 - 00, 01, 10, 11 -.
> How does GNU Radio manage this since for BPSK you can assign each input
> value to only two constellation points
>
> In my real implementation I am using 0 only as input value because I
> want to prove that the transceiver works using only one constellation.
> Unfortunately, the following are the results that I have: please refer
> to the following link
> https://stackoverflow.com/questions/63603899/psk-modulation-in-gnu-radio-in-usrp-n310
>
> I would be immensely grateful if you could help me to clarify the
> questions that I formulate in OpenStackFlow.
>
> Best regards
> Javier Acevedo
>
> Am Do., 27. Aug. 2020 um 02:59 Uhr schrieb Barry Duggan
> <barry@dcsmail.net <mailto:barry@dcsmail.net>>:
>
> For those of you who have been asking questions about BPSK, I have
> created
> https://wiki.gnuradio.org/index.php/Simulation_example:_BPSK_Demodulation,
>
> which is a follow-on to the QPSK tutorial. Questions and comments are
> welcome!
>
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
>

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

Subject: Digest Footer

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

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

End of Discuss-gnuradio Digest, Vol 214, Issue 29
*************************************************