Re: building a ccsds transceiver

Hi

Fisrt I should says, cascading blocks without knowing what each block does should normally don't work.

Personally I never used these ones but they are numerous inconsistencies.

about decoding

• Your sample rate (input of Lime Sink and output of Lime source) is 32 kHz so the GMSK signal is 32 kHz bandwidth
• GMSK help states that "The output is a stream of bits packed 1 bit per byte (the LSB)" so don't convert to float, but just use a  unpack block to extract bits.
  
• CCSD27 decode block use -1 +1 input for 0 -1 bits so you have to convert bits to +1-1 float using a math operation such as input=(2*bit-1.0)
  

I suspect that your received signal is shifted in frequency.  You won't receive anything as soon as the frequency shift is larger than 32 kHz

Suggested action:

• May be you can try modulation + demodulation without hardware, and then with a channel model
  
• look at the received spectrum: is there any signal ?
  
• increased the received bandwith= sampling_rate at LimeSDR source . 32khz*oversampling_factor with oversampling_factor being 5 or 10
• do you see any signal in the spectrum?
  
• if yes add a Xlating filter to shift ad=nd center the received signal
  
• and then you should be able to demodulate it
• However, I don't know if the GMSK demod perform carrier recovery or synchronisation. You should have this feature in your flowgraph for the demod to work.
  

Hope this helps

Regards

On 31/01/2021 17:02, kaihua cheng wrote:

hello , i am trying to build a ccsds transceiver. i got this from someone "Decode CCSDS 27 expects soft symbols, while GMSK demod puts out hard symbols. It would be advisable to use a demodulator that puts out soft symbols, but if you want to keep GMSK demod, then you must convert from char to float". 

but after i have connected everything together, the decoding does not work. can someone help me and tell me what i  should do?

building a ccsds transceiver

hello , i am trying to build a ccsds transceiver. i got this from someone "Decode CCSDS 27 expects soft symbols, while GMSK demod puts out hard symbols. It would be advisable to use a demodulator that puts out soft symbols, but if you want to keep GMSK demod, then you must convert from char to float". 

but after i have connected everything together, the decoding does not work. can someone help me and tell me what i  should do?

Re: cmake doesn't like xrdp

And not to beat a dead horse - but I forgot to mention if you're using a Windows laptop to connect, then you most likely will need to install a X11 server on the Windows laptop - regardless of whether or not you login remotely to a Linux or a Windows machine.

-- Cinaed


And needless to say, if the Windows machine is sending your laptop X11 protocol, then you're dead in the water.

On 1/29/21 2:32 PM, Cinaed Simson wrote:

It's not that xrpd doesn't like cmake, it's that the unknown device running the unknown OS doesn't like you :).

In other words, it's most likely an X authorization problem.

On the unknown device running the unknown OS, try typing

   xhost +

after you connect and see that corrects the problems.

You can test X by typing

  xclock

- assuming it's installed on the unknown device running the unknown OS.

And It could also be a problem with DISPLAY environment variable - but that could be a separate can of worms.

The problem with cmake is probably because after cmake gathers the necessary initial information, it then tries to start

  cmake-qt-gui

-  which requires X.

Without X there can be no graphics.

Or it could be worse - there is no X - but since it appears it's trying to start cmake-qt-gui - it probably has X.

If you log into the VM at the console, then you're owner of X so there's no problem.

-- Cinaed

 

On 1/29/21 10:10 AM, Gavin Jacobs wrote:

For two weeks I have been trying to build a new module/block on 3.9 without much success. You can see some of the pain here:

https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00073.html

I finally discovered the cause of the problem and a workaround.

If you are running a remote session via xrdp, then the cmake step of gr_modtool, or building 3.9 from source, or just about any cmake involving gnuradio-runtime, will NOT work. You get error messages about a non-existent "/include" directory. 

I discovered this by accident. I was getting frustrated with trying different things, so I created a virtual machine (using VMware Player), and kept a copy of the virtual machine with just the OS installed, updated, and configured the way I like it. Then I could try different things and go back to the base if it didn't work out. Yesterday I found that I could build the 3.9 maint branch from source on the vm, without the cmake errors. I also used gr_modtool to make a trivial block, and that worked too. Encouraged by this result, I went back to the laptop via xrdp and tried it there, and got the same old errors. In desperation, I tried the procedure on the laptop directly (which is a nuisance because it is in the basement, in a cold room, and not readily accessible), and it worked! Still haven't figured out what the difference is. So now, I have a development environment in a vm. I'm hoping I can do the code/test/edit/rebuild cycle on the target machine using xrdp, but we'll see what happens.

Also, here are a few other things that I learned:

"gr_modtool add" will complain about clang-format, so install that along with the prerequisites

"gr_modtool makeyaml" is not worth the trouble, it's easier to edit the file that was created by "gr_modtool add" 

the in-tree blocks on github are not great examples for beginners, the example on the wiki is better

Hope that helps someone.

Re: cmake doesn't like xrdp

It's not that xrpd doesn't like cmake, it's that the unknown device running the unknown OS doesn't like you :).

In other words, it's most likely an X authorization problem.

On the unknown device running the unknown OS, try typing

   xhost +

after you connect and see that corrects the problems.

You can test X by typing

  xclock

- assuming it's installed on the unknown device running the unknown OS.

And It could also be a problem with DISPLAY environment variable - but that could be a separate can of worms.

The problem with cmake is probably because after cmake gathers the necessary initial information, it then tries to start

  cmake-qt-gui

-  which requires X.

Without X there can be no graphics.

Or it could be worse - there is no X - but since it appears it's trying to start cmake-qt-gui - it probably has X.

If you log into the VM at the console, then you're owner of X so there's no problem.

-- Cinaed

 

On 1/29/21 10:10 AM, Gavin Jacobs wrote:

For two weeks I have been trying to build a new module/block on 3.9 without much success. You can see some of the pain here:

https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00073.html

I finally discovered the cause of the problem and a workaround.

If you are running a remote session via xrdp, then the cmake step of gr_modtool, or building 3.9 from source, or just about any cmake involving gnuradio-runtime, will NOT work. You get error messages about a non-existent "/include" directory. 

I discovered this by accident. I was getting frustrated with trying different things, so I created a virtual machine (using VMware Player), and kept a copy of the virtual machine with just the OS installed, updated, and configured the way I like it. Then I could try different things and go back to the base if it didn't work out. Yesterday I found that I could build the 3.9 maint branch from source on the vm, without the cmake errors. I also used gr_modtool to make a trivial block, and that worked too. Encouraged by this result, I went back to the laptop via xrdp and tried it there, and got the same old errors. In desperation, I tried the procedure on the laptop directly (which is a nuisance because it is in the basement, in a cold room, and not readily accessible), and it worked! Still haven't figured out what the difference is. So now, I have a development environment in a vm. I'm hoping I can do the code/test/edit/rebuild cycle on the target machine using xrdp, but we'll see what happens.

Also, here are a few other things that I learned:

"gr_modtool add" will complain about clang-format, so install that along with the prerequisites

"gr_modtool makeyaml" is not worth the trouble, it's easier to edit the file that was created by "gr_modtool add" 

the in-tree blocks on github are not great examples for beginners, the example on the wiki is better

Hope that helps someone.

GNU Radio Conference 2021 - Call for Participation

Greetings GNU Radio Community! 

We are gearing up for GNU Radio Conference 2021, which will be held September 20-24, 2021. GRCon 2021 celebrates and showcases the substantial and remarkable progress of GNU Radio and its usage in a diverse field of applications and industries.  It is a week-long conference that includes high-quality technical content and valuable networking opportunities. GRCon is a venue that highlights design, implementation, and theory that has been practically applied in a useful way. GRCon attendees come from a large variety of backgrounds, including industry, academia, government, and hobbyists.

GRCon21 is fully setup to run in-person in Charlotte, North Carolina. However with COVID still a significant concern the decision of whether to confirm that setup or move entirely online will not be made until April. This will be the next major breakpoint where the organizing committee will evaluate on the current conditions and make decisions on what is safe and sensible. In either case the main track talks will be livestreamed similar to GRCon20. 

If in-person, Charlotte, NC - the home of NASCAR, is the perfect location to focus on the theme of SPEED: processing high rate high throughput data with GNU Radio and showcase many of the high performance platforms and applications that have been developed across our community.  To find out more about Charlotte, including venue information, please visit here: https://www.gnuradio.org/grcon/grcon21/charlotte

*** We invite developers and users from across the GNU Radio Community to present your projects, presentations, papers, posters, and problems at GNU Radio Conference 2021, so start thinking about what great work you would like to present at this year's conference. ***  The proposal submission system will be up and running March 5th. 

To sign up for email updates to find out about key upcoming decisions and dates (submissions, registrations, virtual vs in-person) - please pre-register here:   https://tickets.gnuradio.org/grcon21/

Key Dates

• March 5 - Open for Submissions
• April - Evaluation of in-person or purely online
• April - Start of ticket sales
• June 9 - 1st Round of Submissions closes
• August 2 - Main track schedule posted
• September 20 - Conference starts

Looking forward to another amazing conference!

Sincerely,

The GRCON21 Organizers

cmake doesn't like xrdp

For two weeks I have been trying to build a new module/block on 3.9 without much success. You can see some of the pain here:

https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00073.html

I finally discovered the cause of the problem and a workaround.

If you are running a remote session via xrdp, then the cmake step of gr_modtool, or building 3.9 from source, or just about any cmake involving gnuradio-runtime, will NOT work. You get error messages about a non-existent "/include" directory. 

I discovered this by accident. I was getting frustrated with trying different things, so I created a virtual machine (using VMware Player), and kept a copy of the virtual machine with just the OS installed, updated, and configured the way I like it. Then I could try different things and go back to the base if it didn't work out. Yesterday I found that I could build the 3.9 maint branch from source on the vm, without the cmake errors. I also used gr_modtool to make a trivial block, and that worked too. Encouraged by this result, I went back to the laptop via xrdp and tried it there, and got the same old errors. In desperation, I tried the procedure on the laptop directly (which is a nuisance because it is in the basement, in a cold room, and not readily accessible), and it worked! Still haven't figured out what the difference is. So now, I have a development environment in a vm. I'm hoping I can do the code/test/edit/rebuild cycle on the target machine using xrdp, but we'll see what happens.

Also, here are a few other things that I learned:

"gr_modtool add" will complain about clang-format, so install that along with the prerequisites

"gr_modtool makeyaml" is not worth the trouble, it's easier to edit the file that was created by "gr_modtool add" 

the in-tree blocks on github are not great examples for beginners, the example on the wiki is better

Hope that helps someone.

Re: Migration 3.7 to 3.8 - GRC OOT module fails to import multi_usrp

Resolved:

the 3.7 to 3.8 migration guide shows components must be added to the CMake:

I am using the UHD component, so added as such

> 3.7.2
> set(GR_REQUIRED_COMPONENTS RUNTIME PMT UHD)
> find_package(Gnuradio "3.7.2" REQUIRED)
>
> 3.8.2
> find_package(Gnuradio "3.8" REQUIRED COMPONENTS UHD)
> include(GrVersion)
Also, the CMake in the lib directory must be updated, adding uhd
> target_link_libraries(gnuradio-vandevender gnuradio::gnuradio-runtime uhd)


Criss Swaim
cswaim@tpginc.net
cell: 505.301.5701

On 1/28/2021 2:55 PM, Criss Swaim wrote:
> I am running Fedora 33, GnuRadio 3.8.2 and UHD 3.15.  GnuRadio/UHD was
> installed from the dnf package with the following command:
>
>> dnf install -y gnuradio3.8 uhd-devel gnuradio-devel uhd-tools
> Following the OOT tutorial I have updated the cmake as follows:
>
>> 3.7.2
>> set(GR_REQUIRED_COMPONENTS RUNTIME PMT UHD)
>> find_package(Gnuradio "3.7.2" REQUIRED)
>>
>> 3.8.2
>> find_package(Gnuradio "3.8" REQUIRED COMPONENTS UHD)
>> include(GrVersion)
> After compiling my OOT module, the compile is clean, but running the
> block in grc I receive an error.
>
>> ImportError:
>> /home/sensor/qn382/gr-vandevender/build/lib/libgnuradio-vandevender.so.1.0.0git:
>> undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_CHANSE
> in the OOTcmodule, there is this line of code:
>
>> usrp = uhd::usrp::multi_usrp::make(ip_addr);
> To debug, I opened ipython and imported the swig file and am receiving
> the following error (thank you Martin Braun for this debugging tip):
>
>> In [1]: import swig._vandevender_swig
>> ---------------------------------------------------------------------------
>> ImportError                               Traceback (most recent call
>> last)
>> <ipython-input-1-48c182e2abc0> in <module>
>> ----> 1 import swig._vandevender_swig
>>
>> ImportError:
>> /home/sensor/qn382/gr-vandevender/build/lib/libgnuradio-vandevender.so.1.0.0git:
>> undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_CHANSE
> In ipython, I have imported uhd.usrp and dir(uhd.usrp.lib.usrp) finds
> the multi_ursp function is found,  
>
> So I suspect I need something, somewhere in the CMake file is needed to
> point swig to the correct python module uhd.usrp.lib.usrp.  But I am
> lost.  Is this even the correct area?  Are there other areas I need to
> look into?  This is my first exposure to the 'modern CMake', so if the
> problem is in it, some specific guidance would be appreciated.
>

Re: New Raspberry PI Complete OS release

Hi Glen,

this is nice! Thanks!
If you could tell us what specifically is a blocker for porting to 3.8 (or anything later,
for that matter), people might be able to help exactly that. I know you're not content
with the changes we've made, but I know how much effort flows into maintaining a complex
system such as your Radio Astronomy Operating System, and as I think the community
benefits from such projects, my experience is that there'll be experience and hands able
to help getting whatever it is that you need ported to a modern GNU Radio, especially
because that means you can go and use the GNU Radio that modern Linux distros offer "out
of the box" and don't have to roll your own.

Also, don't be afraid: 3.8 is not going away soon, and the migration from 3.8 to 3.9 is
really not that big of a thing, basically all names stayed the same.

Best regards,
Marcus


On 28.01.21 18:22, Glen I Langston wrote:
> Hello
>
> We've been successful in simultaneous radio astronomy with high schools in the US, including
> California, North Carolina, Illinois, Virginia, New York and West Virginia.
>
> We'd like to expand to southern hemisphere as well, so that we can get a full sky image
> of the Milky Way.
>
> We've just released a new version of the complete Radio Astronomy Operating system
> for Raspberry Pi 4 computers. The whole 12 GB Os is compressed to 3.4 GB for download.
> https://drive.google.com/file/d/1PwjSfVUlV4XNyaDtzrgMiI4Z7IL6HGi2/view?usp=sharing
>
> The installation guide has the link to the OS as well. All are on Google Drive
> https://docs.google.com/document/d/1pStZsguO3UMrP0FhxJJJPFYdkg-Bp8TG3_zIh8MYHUQ/edit?usp=sharing
>
> The newest version automatically puts all observations on the included Apache web server for
> sharing with other high schools/hobbyists.
>
> FYI you can measure the effective noise temperature of your first LNA using the software
> included in the OS and described in LightWork Memo 28.
> https://drive.google.com/file/d/1T6y3XJ9PyVhMCDVL0gaL-mx1BI6bUyEN/view?usp=sharing
>
> I'm still stuck at GNURadio 3.13.7.5, but have a few C++ programs converted to 3.8
> and running. Maybe just before 3.8 is obsolete I'll catch up.
>
> Best regards
>
> Glen
>
>

Migration 3.7 to 3.8 - GRC OOT module fails to import multi_usrp

I am running Fedora 33, GnuRadio 3.8.2 and UHD 3.15.  GnuRadio/UHD was
installed from the dnf package with the following command:

> dnf install -y gnuradio3.8 uhd-devel gnuradio-devel uhd-tools

Following the OOT tutorial I have updated the cmake as follows:

> 3.7.2
> set(GR_REQUIRED_COMPONENTS RUNTIME PMT UHD)
> find_package(Gnuradio "3.7.2" REQUIRED)
>
> 3.8.2
> find_package(Gnuradio "3.8" REQUIRED COMPONENTS UHD)
> include(GrVersion)
After compiling my OOT module, the compile is clean, but running the
block in grc I receive an error.

> ImportError:
> /home/sensor/qn382/gr-vandevender/build/lib/libgnuradio-vandevender.so.1.0.0git:
> undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_CHANSE

in the OOTcmodule, there is this line of code:

> usrp = uhd::usrp::multi_usrp::make(ip_addr);
To debug, I opened ipython and imported the swig file and am receiving
the following error (thank you Martin Braun for this debugging tip):

> In [1]: import swig._vandevender_swig
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call
> last)
> <ipython-input-1-48c182e2abc0> in <module>
> ----> 1 import swig._vandevender_swig
>
> ImportError:
> /home/sensor/qn382/gr-vandevender/build/lib/libgnuradio-vandevender.so.1.0.0git:
> undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_CHANSE
In ipython, I have imported uhd.usrp and dir(uhd.usrp.lib.usrp) finds
the multi_ursp function is found,  

So I suspect I need something, somewhere in the CMake file is needed to
point swig to the correct python module uhd.usrp.lib.usrp.  But I am
lost.  Is this even the correct area?  Are there other areas I need to
look into?  This is my first exposure to the 'modern CMake', so if the
problem is in it, some specific guidance would be appreciated.

--
Criss Swaim
cswaim@tpginc.net
cell: 505.301.5701

New Raspberry PI Complete OS release

Hello

We've been successful in simultaneous radio astronomy with high schools in the US, including
California, North Carolina, Illinois, Virginia, New York and West Virginia.

We'd like to expand to southern hemisphere as well, so that we can get a full sky image
of the Milky Way.

We've just released a new version of the complete Radio Astronomy Operating system
for Raspberry Pi 4 computers. The whole 12 GB Os is compressed to 3.4 GB for download.
https://drive.google.com/file/d/1PwjSfVUlV4XNyaDtzrgMiI4Z7IL6HGi2/view?usp=sharing

The installation guide has the link to the OS as well. All are on Google Drive
https://docs.google.com/document/d/1pStZsguO3UMrP0FhxJJJPFYdkg-Bp8TG3_zIh8MYHUQ/edit?usp=sharing

The newest version automatically puts all observations on the included Apache web server for
sharing with other high schools/hobbyists.

FYI you can measure the effective noise temperature of your first LNA using the software
included in the OS and described in LightWork Memo 28.
https://drive.google.com/file/d/1T6y3XJ9PyVhMCDVL0gaL-mx1BI6bUyEN/view?usp=sharing

I'm still stuck at GNURadio 3.13.7.5, but have a few C++ programs converted to 3.8
and running. Maybe just before 3.8 is obsolete I'll catch up.

Best regards

Glen

Re: "modules" GMP and MPIR;3.9.0.0

gmp and mpir are actually the same library with different names. On
Ubuntu, only gmp is available as a package. If CMake finds either one
(or both), it will say "Found MPLIB" (or "Dependency MPLIB_FOUND = TRUE"
later on).

You're missing Thrift, but that library is not required. Same thing with
pygccxml.

The most important thing to check is the list of Gnuradio
enabled/disabled components at the end.

Ron

On 1/27/21 22:39, lists@lazygranch.com wrote:
> This sure is crypic. So missing MPIR but finding MPLIB is the same
> thing?
>
> Dependency MPLIB_FOUND = TRUE
>
> And this means I actually did find THIRFT?
> Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND)
>
> Do these "cancel"?
> -- Python checking for pygccxml - not found
> -- Found PythonInterp: /usr/bin/python3 (found version "3.6.12")
>
> I don't even see the GMP complaint anymore.
>
>
>
> On Wed, 27 Jan 2021 20:16:45 -0800
> Ron Economos <w6rz@comcast.net> wrote:
>
>> You're actually okay. Your version of CMake doesn't seem to print out
>> when it finds modules (which are libraries). On Ubuntu, it looks like
>> this:
>>
>> -- Configuring VOLK support...
>> -- Found Volk: Volk::volk
>> --   Found VOLK:
>> --   * Version: 2.4.1
>> --   * Libraries: Volk::volk
>> --   * Includes: /opt/gnuradio-3.9.0git/include
>> -- Found LOG4CPP: /usr/local/lib/liblog4cpp.so
>> -- Not using additional GNU Radio native architecture optimizations.
>> -- Performing Test HAVE_CX_LIMITED_RANGE
>> -- Performing Test HAVE_CX_LIMITED_RANGE - Success
>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>> -- Checking for module 'gmp'
>> --   No package 'gmp' found
>> -- Found GMP: /usr/lib/arm-linux-gnueabihf/libgmpxx.so
>> -- Checking for module 'mpir >= 3.0'
>> --   No package 'mpir' found
>> -- Found MPIR: /usr/local/lib/libmpirxx.so
>> -- Found MPLIB: /usr/lib/arm-linux-gnueabihf/libgmpxx.so
>

Re: "modules" GMP and MPIR;3.9.0.0

This sure is crypic. So missing MPIR but finding MPLIB is the same
thing?

Dependency MPLIB_FOUND = TRUE

And this means I actually did find THIRFT?
Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND)

Do these "cancel"?
-- Python checking for pygccxml - not found
-- Found PythonInterp: /usr/bin/python3 (found version "3.6.12")

I don't even see the GMP complaint anymore.



On Wed, 27 Jan 2021 20:16:45 -0800
Ron Economos <w6rz@comcast.net> wrote:

> You're actually okay. Your version of CMake doesn't seem to print out
> when it finds modules (which are libraries). On Ubuntu, it looks like
> this:
>
> -- Configuring VOLK support...
> -- Found Volk: Volk::volk
> --   Found VOLK:
> --   * Version: 2.4.1
> --   * Libraries: Volk::volk
> --   * Includes: /opt/gnuradio-3.9.0git/include
> -- Found LOG4CPP: /usr/local/lib/liblog4cpp.so
> -- Not using additional GNU Radio native architecture optimizations.
> -- Performing Test HAVE_CX_LIMITED_RANGE
> -- Performing Test HAVE_CX_LIMITED_RANGE - Success
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
> -- Checking for module 'gmp'
> --   No package 'gmp' found
> -- Found GMP: /usr/lib/arm-linux-gnueabihf/libgmpxx.so
> -- Checking for module 'mpir >= 3.0'
> --   No package 'mpir' found
> -- Found MPIR: /usr/local/lib/libmpirxx.so
> -- Found MPLIB: /usr/lib/arm-linux-gnueabihf/libgmpxx.so

Re: "modules" GMP and MPIR;3.9.0.0

You're actually okay. Your version of CMake doesn't seem to print out
when it finds modules (which are libraries). On Ubuntu, it looks like this:

-- Configuring VOLK support...
-- Found Volk: Volk::volk
--   Found VOLK:
--   * Version: 2.4.1
--   * Libraries: Volk::volk
--   * Includes: /opt/gnuradio-3.9.0git/include
-- Found LOG4CPP: /usr/local/lib/liblog4cpp.so
-- Not using additional GNU Radio native architecture optimizations.
-- Performing Test HAVE_CX_LIMITED_RANGE
-- Performing Test HAVE_CX_LIMITED_RANGE - Success
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'gmp'
--   No package 'gmp' found
-- Found GMP: /usr/lib/arm-linux-gnueabihf/libgmpxx.so
-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Found MPIR: /usr/local/lib/libmpirxx.so
-- Found MPLIB: /usr/lib/arm-linux-gnueabihf/libgmpxx.so
--

Libraries can be found in one of two ways. If the first one fails, CMake
will print "No package 'xxx' found". But if the second one succeeds, it
will print "Found XXX: /some/path/to/library". If both fail (and the
library is required), you'll know it because CMake will exit immediately
with an error.

Ron

On 1/27/21 18:13, lists@lazygranch.com wrote:
> Building 3.9.0.0 on opensuse 15.2. I did
> git checkout maint-3.9
> I'm using volk from the repo. (not building it)
>
>
> The terminology "module" confuses me. Does this refer to gnuradio code
> or some library on my computer? I believe I have gmp and mpir available.
>
>
> -- Checking for module 'gmp'
> -- No package 'gmp' found
> -- Checking for module 'mpir >= 3.0'
> -- No package 'mpir' found

"modules" GMP and MPIR;3.9.0.0

Building 3.9.0.0 on opensuse 15.2. I did
git checkout maint-3.9
I'm using volk from the repo. (not building it)


The terminology "module" confuses me. Does this refer to gnuradio code
or some library on my computer? I believe I have gmp and mpir available.


-- Checking for module 'gmp'
-- No package 'gmp' found
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
--
-- Configuring post-install support...
-- Enabling post-install support.
-- Override with -DENABLE_POSTINSTALL=ON/OFF
--
-- Configuring doxygen support...
-- Dependency DOXYGEN_FOUND = YES
-- Enabling doxygen support.
-- Override with -DENABLE_DOXYGEN=ON/OFF
-- Checking for module 'gmp'
-- No package 'gmp' found
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found

-- Python checking for Thrift - not found
-- Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND)

The entire output from cmake follows. Ignore the QT issue. QT needs an
upgrade but I need to check with the opesuse gurus before I mess with
KDE. It wants to change 149 files. (Need to image before doing that.)

--------------------------------------------------------
cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../ -- Build type set to Release.
--
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
--
-- Configuring testing-support support...
-- Dependency Boost_unit_test_framework_FOUND = ON
-- Enabling testing-support support.
-- Override with -DENABLE_TESTING=ON/OFF
-- Extracting version information from git describe...
CMake Warning at CMakeLists.txt:87 (MESSAGE):


The compiler selected to build GNU Radio (GCC version 7.5.0 : /usr/bin/c++)
is older than that officially supported (8.3.0 minimum). This build may or
not work. We highly recommend using a more recent GCC version.


-- Compiler Version: cc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f55b3d993b32e5c]
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
-- ADDING PERF COUNTERS
-- User set python executable /usr/bin/python3
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.12", minimum required is "3.6.5")
-- Python checking for numpy - found
-- Python checking for pygccxml - not found
-- Found PythonInterp: /usr/bin/python3 (found version "3.6.12")
--
-- Configuring python-support support...
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency pybind11_FOUND = 1
-- Dependency NUMPY_FOUND = TRUE
-- Enabling python-support support.
-- Override with -DENABLE_PYTHON=ON/OFF
--
-- Configuring VOLK support...
-- Found VOLK:
-- * Version: 2.4.1
-- * Libraries: Volk::volk
-- * Includes: /usr/include
-- Not using additional GNU Radio native architecture optimizations.
-- Checking for module 'gmp'
-- No package 'gmp' found
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
--
-- Configuring post-install support...
-- Enabling post-install support.
-- Override with -DENABLE_POSTINSTALL=ON/OFF
--
-- Configuring doxygen support...
-- Dependency DOXYGEN_FOUND = YES
-- Enabling doxygen support.
-- Override with -DENABLE_DOXYGEN=ON/OFF
-- Checking for module 'gmp'
-- No package 'gmp' found
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
--
-- Configuring gnuradio-runtime support...
-- Dependency Boost_FOUND = TRUE
-- Dependency PYTHONINTERP_FOUND = TRUE
-- Dependency MPLIB_FOUND = TRUE
-- Dependency LOG4CPP_FOUND = TRUE
-- Dependency pybind11_FOUND = 1
-- Enabling gnuradio-runtime support.
-- Override with -DENABLE_GNURADIO_RUNTIME=ON/OFF
--
-- Configuring gr-ctrlport support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Enabling gr-ctrlport support.
-- Override with -DENABLE_GR_CTRLPORT=ON/OFF
-- Loading build date Thu, 28 Jan 2021 01:43:15 into constants...
-- Loading version 3.9.0.0 into constants...
-- Python checking for Thrift - not found
-- Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND)
-- TRY_SHM_VMCIRCBUF set to ON.
--
-- Python checking for PyYAML >= 3.10 - found
-- Python checking for mako >= 1.0.7 - found
-- Python checking for pygobject >= 2.28.6 - found
-- Python checking for Gtk (GI) >= 3.10.8 - found
-- Python checking for Cairo (GI) >= 1.0 - found
-- Python checking for PangoCairo (GI) >= 1.0 - found
-- Python checking for numpy - found
--
-- Configuring gnuradio-companion support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_PYTHON = ON
-- Dependency PYYAML_FOUND = TRUE
-- Dependency MAKO_FOUND = TRUE
-- Dependency PYGI_FOUND = TRUE
-- Dependency GTK_GI_FOUND = TRUE
-- Dependency CAIRO_GI_FOUND = TRUE
-- Dependency PANGOCAIRO_GI_FOUND = TRUE
-- Dependency NUMPY_FOUND = TRUE
-- Enabling gnuradio-companion support.
-- Override with -DENABLE_GRC=ON/OFF
-- Python checking for pytest - found
--
-- Configuring gr-blocks support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Enabling gr-blocks support.
-- Override with -DENABLE_GR_BLOCKS=ON/OFF
--
-- Configuring gr-fec support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Enabling gr-fec support.
-- Override with -DENABLE_GR_FEC=ON/OFF
--
-- Configuring gr-fft support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency FFTW3f_FOUND = TRUE
-- Enabling gr-fft support.
-- Override with -DENABLE_GR_FFT=ON/OFF
--
-- Configuring gr-filter support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Enabling gr-filter support.
-- Override with -DENABLE_GR_FILTER=ON/OFF
--
-- Configuring gr-analog support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Enabling gr-analog support.
-- Override with -DENABLE_GR_ANALOG=ON/OFF
--
-- Configuring gr-digital support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Enabling gr-digital support.
-- Override with -DENABLE_GR_DIGITAL=ON/OFF
--
-- Configuring gr-dtv support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency ENABLE_GR_FEC = ON
-- Enabling gr-dtv support.
-- Override with -DENABLE_GR_DTV=ON/OFF
--
-- Configuring gr-audio support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Enabling gr-audio support.
-- Override with -DENABLE_GR_AUDIO=ON/OFF
-- Found ALSA 1.1.5
-- Found jack: /usr/lib64/libjack.so
--
-- Configuring gr-channels support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Enabling gr-channels support.
-- Override with -DENABLE_GR_CHANNELS=ON/OFF
-- Python checking for PyQt5 - found
-- Checking for module 'Qt5Qwt6'
-- No package 'Qt5Qwt6' found
--
-- Configuring gr-qtgui support...
-- Dependency Boost_FOUND = TRUE
-- Dependency QT_FOUND = 0
-- Dependency QWT_FOUND = FALSE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency PYTHONLIBS_FOUND = TRUE
-- Dependency PYQT5_FOUND = TRUE
-- Disabling gr-qtgui support.
-- Override with -DENABLE_GR_QTGUI=ON/OFF
--
-- Configuring gr-trellis support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_DIGITAL = ON
-- Enabling gr-trellis support.
-- Override with -DENABLE_GR_TRELLIS=ON/OFF
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
The package name passed to `find_package_handle_standard_args` (PkgConfig)
does not match the name of the calling package (UHD). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPkgConfig.cmake:45 (find_package_handle_standard_args)
/usr/lib64/cmake/uhd/UHDConfig.cmake:42 (include)
cmake/Modules/FindUHD.cmake:43 (find_package)
gr-uhd/CMakeLists.txt:13 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

--
-- Configuring gr-uhd support...
-- Dependency Boost_FOUND = TRUE
-- Dependency UHD_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Enabling gr-uhd support.
-- Override with -DENABLE_GR_UHD=ON/OFF
-- UHD Version: 4.0.0.0-0-unknown
-- UHD 4.0 RFNoC enabled: TRUE
-- Python checking for Mako >= 1.0.7 - found
-- Python checking for click - found
-- Python checking for click-plugins - found
--
-- Configuring gr-utils support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_PYTHON = ON
-- Dependency MAKO_FOUND = TRUE
-- Enabling gr-utils support.
-- Override with -DENABLE_GR_UTILS=ON/OFF
--
-- Configuring gr_modtool support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_PYTHON = ON
-- Dependency CLICK_FOUND = TRUE
-- Dependency CLICK_PLUGINS_FOUND = TRUE
-- Enabling gr_modtool support.
-- Override with -DENABLE_GR_MODTOOL=ON/OFF
--
-- Configuring gr_blocktool support...
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_PYTHON = ON
-- Enabling gr_blocktool support.
-- Override with -DENABLE_GR_BLOCKTOOL=ON/OFF
--
-- Configuring gr-video-sdl support...
-- Dependency SDL_FOUND = TRUE
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Enabling gr-video-sdl support.
-- Override with -DENABLE_GR_VIDEO_SDL=ON/OFF
--
-- Configuring gr-vocoder support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_FFT = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_FILTER = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Enabling gr-vocoder support.
-- Override with -DENABLE_GR_VOCODER=ON/OFF
--
-- Configuring gr-wavelet support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ENABLE_GR_BLOCKS = ON
-- Dependency ENABLE_GR_ANALOG = ON
-- Dependency GSL_FOUND = TRUE
-- Enabling gr-wavelet support.
-- Override with -DENABLE_GR_WAVELET=ON/OFF
--
-- Configuring gr-zeromq support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Dependency ZEROMQ_FOUND = TRUE
-- Enabling gr-zeromq support.
-- Override with -DENABLE_GR_ZEROMQ=ON/OFF
--
-- Configuring gr-network support...
-- Dependency Boost_FOUND = TRUE
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Enabling gr-network support.
-- Override with -DENABLE_GR_NETWORK=ON/OFF
-- Using install prefix: /usr/local
-- Building for version: 3.9.0.0 / 3.9.0
-- No C++ unit tests... skipping
--
-- ######################################################
-- # Gnuradio enabled components
-- ######################################################
-- * testing-support
-- * python-support
-- * post-install
-- * doxygen
-- * gnuradio-runtime
-- * gr-ctrlport
-- * gnuradio-companion
-- * gr-blocks
-- * gr-fec
-- * gr-fft
-- * gr-filter
-- * gr-analog
-- * gr-digital
-- * gr-dtv
-- * gr-audio
-- * * alsa
-- * * oss
-- * * jack
-- * * portaudio
-- * gr-channels
-- * gr-trellis
-- * gr-uhd
-- * gr-utils
-- * gr_modtool
-- * gr_blocktool
-- * gr-video-sdl
-- * gr-vocoder
-- * * codec2
-- * * freedv
-- * * gsm
-- * gr-wavelet
-- * gr-zeromq
-- * gr-network
--
-- ######################################################
-- # Gnuradio disabled components
-- ######################################################
-- * gr-qtgui
--
-- Using install prefix: /usr/local
-- Building for version: 3.9.0.0 / 3.9.0
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/src/gnuradio/buil

Re: [announcement] Release 3.9.0.0

Barry,

Thanks for the advice. I tried that, but it didn't work. I get numerous errors during the cmake stage. Here is an excerpt of the output where the errors start:

< ... several hundred lines of progress messages >

-- Using install prefix: /usr/local

-- Building for version: 3.9.0.0 / 3.9.0

-- Configuring done

CMake Error in gnuradio-runtime/lib/CMakeLists.txt:

  Imported target "Boost::unit_test_framework" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

I assume this has been done by numerous others, so I'm guessing that it's one of these possibilities:

• problem with Ubuntu 20.04.1
• missing an undocumented prerequisite or dependancy
• missing step in the documentation/procedure

If you know what causes that, great, I'll try again; but if you don't know, just let it go. At this point I'm just going to wait until the binary package is ready. If you want someone to test that new binary package, I'm willing to do that.

My goals were to setup a 3.9 development system so I could:

• update my Stream/Select block (and a few other trivial blocks I wrote)
  
• develop a new block to decode railway DPU transmissions
• develop a proper sink/source block for the Hackrf

None of these are urgent, so I can wait until the install kinks get worked out. I'm willing to help test, but I don't know how to debug cmake, so I would need some training/guidance to be of any use with that.

Gavin

---

From: Barry Duggan <barry@dcsmail.net>
Sent: January 25, 2021 2:29 PM
To: apriljunkbox@hotmail.com <apriljunkbox@hotmail.com>
Cc: Discuss Gnuradio <discuss-gnuradio@gnu.org>
Subject: RE: [announcement] Release 3.9.0.0

 

Hi Gavin,

There will be a ppa:gnuradio/gnuradio-releases-3.9 but it's not ready yet.

If you want to build 3.9 from source, follow
https://wiki.gnuradio.org/index.php/InstallingGR#From_Source but in
https://wiki.gnuradio.org/index.php/InstallingGR#Step_3:_Installing_GNU_Radio
after "cd gnuradio" do a "git checkout maint-3.9" before the "mkdir
build" so that you have a stable version 3.9.0.0

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

On Wed, 20 Jan 2021 23:31:38 +0000, Gavin Jacobs wrote:

Will the 3.9.0.0 release be available via:
$ sudo add-apt-repository ppa:gnuradio/gnuradio-releases

If so, what is the expected timeframe?
If not, can someone give the right procedure to install on Ubuntu?

Thanks,
Gavin

Re: Debugging OOT Python code in VS Code

Thanks very much Marcus!

I will look into it!

George

On Tue, Jan 26, 2021 at 1:30 PM Marcus Müller <mmueller@gnuradio.org> wrote:

Hi George,

you're in luck: there just recently was a discussion on that here (Subject "How to debug
python blocks."):

https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00142.html

Check out whether that helps you!

Best regards,
Marcus

On 26.01.21 17:33, George Edwards wrote:
> Hello,
>
> I am debugging my OOT Python code in VS Code and it runs pass the Breakpoint. I have
> debugged C++ code in the past in VS Code and it recognises breakpoints and stop, but the
> Python code debugging does not.
>
> I will appreciate any help offered. Thank you!
>
> Regards,
> George

Re: Debugging OOT Python code in VS Code

Hi George,

you're in luck: there just recently was a discussion on that here (Subject "How to debug
python blocks."):

https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00142.html

Check out whether that helps you!

Best regards,
Marcus

On 26.01.21 17:33, George Edwards wrote:
> Hello,
>
> I am debugging my OOT Python code in VS Code and it runs pass the Breakpoint. I have
> debugged C++ code in the past in VS Code and it recognises breakpoints and stop, but the
> Python code debugging does not.
>
> I will appreciate any help offered. Thank you!
>
> Regards,
> George

Debugging OOT Python code in VS Code

Hello,

I am debugging my OOT Python code in VS Code and it runs pass the Breakpoint. I have debugged C++ code in the past in VS Code and it recognises breakpoints and stop, but the Python code debugging does not.

I will appreciate any help offered. Thank you!

Regards,

George

Re: N310 TX with external LO

On 01/26/2021 06:26 AM, Damon qiu wrote:

Dear Madam/Sir,

     Recently, I had encountered a problem that was the synchronization of signal between the four channels of USRP N310.  For sloving this problem, I used to the mode of external local oscillator (LO) of N310. As this article says (https://kb.ettus.com/N300/N310),  a power divider was used to LO inputting signal into two channels. The amplitude of two channels of LO input was about 3dBm. The LO input frequency was twice the frequency of the desired RF output frequency. Then, the system was switched to the mode of  external LO in the GNU Radio software.

   However, no signal was be output except noise,as shown in figure 1. The figure 2 was the output signal in the modle of internal LO. Plesee help me to slove this problem!

Best regards,

Damon

What is the desired frequency?

What device argument is being used?  You should use "tx_lo_source=external" in the device argument.

N310 TX with external LO

Dear Madam/Sir,

     Recently, I had encountered a problem that was the synchronization of signal between the four channels of USRP N310.  For sloving this problem, I used to the mode of external local oscillator (LO) of N310. As this article says (https://kb.ettus.com/N300/N310),  a power divider was used to LO inputting signal into two channels. The amplitude of two channels of LO input was about 3dBm. The LO input frequency was twice the frequency of the desired RF output frequency. Then, the system was switched to the mode of  external LO in the GNU Radio software.

   However, no signal was be output except noise,as shown in figure 1. The figure 2 was the output signal in the modle of internal LO. Plesee help me to slove this problem!

Best regards,

Damon

Dear Madam/Sir,

     Recently, I had encountered a problem that was the synchronization of signal between the four channels of USRP N310.  For sloving this problem, I used to the mode of external local oscillator (LO) of N310. As this article says (https://kb.ettus.com/N300/N310),  a power divider was used to LO inputting signal into two channels. The amplitude of two channels of LO input was about 3dBm. The LO input frequency was twice the frequency of the desired RF output frequency. Then, the system was switched to the mode of  external LO in the GNU Radio software.

   However, no signal was be output except noise,as shown in figure 1. The figure 2 was the output signal in the modle of internal LO. Plesee help me to slove this problem!

Best regards,

Damon

Re: Cross compile gnuradio in E312 error

On 1/25/21 12:38 PM, Marcus D. Leech wrote:
> On 01/25/2021 01:00 AM, --- via "GNU Radio, the Free & Open-Source
> Toolkit for Software Radio" wrote:
>> Dear friends:
>>      I'm installing rfnoc on E312, when I cross compile gnu radio, I
>> execute this command：cmake -Wno-dev
>> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
>> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
>>
>>  It prompts the following error：
>> zcm@zcm-XPS-8500:~/rfnoc/src/gnuradio/build-arm$ cmake -Wno-dev
>> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
>> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
>> -- Build type not specified: defaulting to release.
>> -- Build type set to Release.
>> -- Extracting version information from git describe...
>> -- Compiler Version: arm-oe-linux-gnueabi-gcc (GCC) 4.9.2
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for
> It looks like your error-log was cut-off.   Could you post again?
>
> You say that you're cross-compiling?  On what host platform?

I'd also check what versions of gcc and boost "rfnoc" requires.

Philip

>
>
>
>
>
>

Re: Migration from 3.7 to 3.8 OOT - module 'howto' has no attribute 'square_ff'

Martin:

Thanks for the debugging hint.  I went back through the tutorial and with the help of this import I was able to determine the problems( code error and I needed to run ldconfig

I went to my 'real' OOT module and import the swig file and receive this message:

ImportError: /home/sensor/qn382/gr-vandevender/build/lib/libgnuradio-vandevender.so.1.0.0git: undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_CHANSE

This seems to be point to the uhd:usrp:multi_usrp - so I am researching.  I wonder if you have any suggestions on where to look for this error.

Again, thanks for the assist.

Criss Swaim  cswaim@tpginc.net  cell: 505.301.5701

On 1/25/2021 2:48 AM, Martin Braun wrote:

Criss,

a good debugging method is to go into the build dir, where you should find a DLL called _howto_swig.so (or something like that). Try importing that:

>>> import _howto_swig

It will probably fail, and will likely give you a better clue of what's going on.

--M

On Sat, Jan 23, 2021 at 12:51 AM Criss Swaim <cswaim@tpginc.net> wrote:

I am upgrading from gnuradio 3.7.2 to 3.8.2 and have run into a couple
of issues with my OOT modules not showing up in the python module.  So I
went back and walked through the HowTo tutorial to see it the tutorial
would work.  It fails also.

OS: Fedora 33


> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> '/tmp/runtime-sensor'
> Traceback (most recent call last):
>   File "/home/sensor/gr-howto/HowTo.py", line 175, in <module>
>     main()
>   File "/home/sensor/gr-howto/HowTo.py", line 151, in main
>     tb = top_block_cls()
>   File "/home/sensor/gr-howto/HowTo.py", line 112, in __init__
>     self.howto_square_ff_0 = howto.square_ff()
> AttributeError: module 'howto' has no attribute 'square_ff'

The libgnuradio-howto.so lib is in /usr/local/lib64

I have added the /usr/local/lib64 directory to ld.so.conf and ran the
sudo ldconfig to reload the lib paths, followed by make/make install. 

When the python howto module is created it does not have the square_ff
entry point:

> dir(howto)
> ['__builtins__', '__cached__', '__doc__', '__file__', '__loader__',
> '__name__', '__package__', '__path__', '__spec__', 'unicode_literals']
Any ideas on where to look next?  I am not sure if this is a path-ing
issue or is something wrong in the building of the python module.

--
Criss Swaim
cswaim@tpginc.net
cell: 505.301.5701

RE: [announcement] Release 3.9.0.0

Hi Gavin,

There will be a ppa:gnuradio/gnuradio-releases-3.9 but it's not ready yet.

If you want to build 3.9 from source, follow
https://wiki.gnuradio.org/index.php/InstallingGR#From_Source but in
https://wiki.gnuradio.org/index.php/InstallingGR#Step_3:_Installing_GNU_Radio
after "cd gnuradio" do a "git checkout maint-3.9" before the "mkdir
build" so that you have a stable version 3.9.0.0

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

On Wed, 20 Jan 2021 23:31:38 +0000, Gavin Jacobs wrote:

Will the 3.9.0.0 release be available via:
$ sudo add-apt-repository ppa:gnuradio/gnuradio-releases

If so, what is the expected timeframe?
If not, can someone give the right procedure to install on Ubuntu?

Thanks,
Gavin

Re: Cross compile gnuradio in E312 error

On 01/25/2021 01:00 AM, --- via "GNU Radio, the Free & Open-Source
Toolkit for Software Radio" wrote:
> Dear friends:
> I'm installing rfnoc on E312, when I cross compile gnu radio, I
> execute this command：cmake -Wno-dev
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
>
> It prompts the following error：
> zcm@zcm-XPS-8500:~/rfnoc/src/gnuradio/build-arm$ cmake -Wno-dev
> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Extracting version information from git describe...
> -- Compiler Version: arm-oe-linux-gnueabi-gcc (GCC) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for
It looks like your error-log was cut-off. Could you post again?

You say that you're cross-compiling? On what host platform?

Re: Performing a USRP Packet Loopback

Jada,

I haven't read up on all the threads in which you've been asking stuff, so this is lacking a bit of context. I still hope it's helpful:

• I don't think you should downgrade UHD. There has been a lot of change in UHD, but not in the B210 driver.
• UHD provides some tools, such an example called "benchmark_rate", which let you test the streaming rates. Those can be helpful to rule out issues. If you can exchange data in those tools fast enough between USRP and computer (in your case the RPi) then that's a good indicator of things working.
• SMA cables are not strictly necessary, and I think in your particular case they might not provide any benefit. They are generally considered a very useful tool though:
• You don't need to worry about receiving stray RF, or polluting the RF environment in your lab
• They provide a good way of controlling the transmission of RF, meaning you have more influence over how the Rx spectrum will look like. Important: You need attenuators as well as cables, because USRPs are designed to receive tiny levels of RF power, and SMA cables will basically carry the full Tx power.
• This might be old news to new, but you should tune the gain settings of your Tx and Rx before attempting to transmit data. I recommend running an app like uhd_fft on your Rx and see if the spectrum looks "good". If you're clipping or distorting, you'll probably notice in the spectrum, and you'll have no chance of transmitting bits.

--M

On Thu, Jan 21, 2021 at 10:30 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Hi, I think I also forgot to mention that I'm very new at working with GNURadio, the boards, and UHD, so I have some follow up questions. 

Regarding Aditya's reply, why would I need to downgrade the version of UHD? And by 'check it', do you mean run the benchmark, transmitting, and receiving examples to see if there's overruns or underruns? Also, what benefit does attaching SMA cables before attaching antennas have? Because I don't have any SMA cables, but if there's some significant benefit I'll look into getting some. 

Regarding Marcus's reply, I've attached a picture of the flowgraph for the packet-tx block so we can determine if it uses start-of-burst/end-of-burst tagging, because I'm not sure how to tell. I think it uses start-of-burst tagging because of the PDU to Tagged Stream blocks at the beginning of the flowgraph but am unsure. Also, if it is the case that it doesn't use start-of-burst/end-of-burst tagging, I found a property of the packet_tx and packet_rx blocks called 'Maxoutbuf'. Could I use these properties to set a buffering policy? And what size buffer would I need?

Again, what I'm trying to do is follow what was said in this message thread. It says that the packet_loopback example is a transceiver, and I can replace the Channel Model blocks with USRP source and USRP sink blocks to try to send a message over the air. I did that, but I'm running into overruns and underrruns and want to know how to fix that. 

Thanks everybody for speedy replies and the help so far! It's much appreciated!!

On Wed, Jan 20, 2021 at 9:11 AM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

On 01/20/2021 12:12 AM, Jada Mariano Berenguer wrote:
> Hi, I realized that in my packet loopback example, I didn't connect
> any of the QT GUI sinks after the USRP source. The updated flow graph
> is attached in screenshot0. After I connected them, I ran the packet
> loopback example on my MacBook Air using one B210 board with TX/RX and
> RX2 antennas attached and got the results attached in screenshot1, but
> still received underruns as printed out in the terminal in the bottom
> left corner. I also ran the example with two B210 boards with a TX/RX
> antenna on one and a RX2 antenna on the other and got slightly
> different results. Instead, the third graph was just a straight
> horizontal line and still ran into underruns. I also ran the same
> program with a Raspberry Pi 4 with one B210 board and got
> similar results. So I don't think it's an issue concerning computer
> power.
>
> Also, I was wondering what you meant by "for a loopback flow at low
> rates you may need to alter the internal buffer sizes in your
> flow-graph to prevent TX starving for samples because the RX buffers
> are still filling. But this is not a distinctly USRP problem and has
> more to do with GnuRadio". How would I alter the internal buffer sizes
> and what would I need to change it to?
>
> Are there any other suggestions you have for me to successfully get
> this loopback example running?
>
> Thanks!
>
My comments on buffer sizes were driven by an incomplete understanding
of what you were doing--however, having said that,
   at low sample rates, the default buffer sizes used by Gnu Radio may
become an issue.

See the Options block to set a global buffering policy:

https://wiki.gnuradio.org/index.php/Options

I'm not that familiar with the blocks you're using in your flow-graph.   
If the packet-tx block doesn't use start-of-burst/end-of-burst tagging,
   the the UHD sink block will underrun between bursts, since it will be
expecting a continuous flow, but only receiving a bursty flow. This may
   not be a problem here--I just don't know how that packet-tx block works.

Re: Migration from 3.7 to 3.8 OOT - module 'howto' has no attribute 'square_ff'

Criss,

a good debugging method is to go into the build dir, where you should find a DLL called _howto_swig.so (or something like that). Try importing that:

>>> import _howto_swig

It will probably fail, and will likely give you a better clue of what's going on.

--M

On Sat, Jan 23, 2021 at 12:51 AM Criss Swaim <cswaim@tpginc.net> wrote:

I am upgrading from gnuradio 3.7.2 to 3.8.2 and have run into a couple
of issues with my OOT modules not showing up in the python module.  So I
went back and walked through the HowTo tutorial to see it the tutorial
would work.  It fails also.

OS: Fedora 33


> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to
> '/tmp/runtime-sensor'
> Traceback (most recent call last):
>   File "/home/sensor/gr-howto/HowTo.py", line 175, in <module>
>     main()
>   File "/home/sensor/gr-howto/HowTo.py", line 151, in main
>     tb = top_block_cls()
>   File "/home/sensor/gr-howto/HowTo.py", line 112, in __init__
>     self.howto_square_ff_0 = howto.square_ff()
> AttributeError: module 'howto' has no attribute 'square_ff'

The libgnuradio-howto.so lib is in /usr/local/lib64

I have added the /usr/local/lib64 directory to ld.so.conf and ran the
sudo ldconfig to reload the lib paths, followed by make/make install. 

When the python howto module is created it does not have the square_ff
entry point:

> dir(howto)
> ['__builtins__', '__cached__', '__doc__', '__file__', '__loader__',
> '__name__', '__package__', '__path__', '__spec__', 'unicode_literals']
Any ideas on where to look next?  I am not sure if this is a path-ing
issue or is something wrong in the building of the python module.

--
Criss Swaim
cswaim@tpginc.net
cell: 505.301.5701

Re: Cross compile gnuradio in E312 error

Hi,

you didn't paste an error message.

--M

On Mon, Jan 25, 2021 at 7:02 AM --- via GNU Radio, the Free & Open-Source Toolkit for Software Radio <discuss-gnuradio@gnu.org> wrote:

Dear friends:

     I'm installing rfnoc on E312, when I cross compile gnu radio, I execute this command：cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../

 It prompts the following error：

zcm@zcm-XPS-8500:~/rfnoc/src/gnuradio/build-arm$ cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../

-- Build type not specified: defaulting to release.

-- Build type set to Release.

-- Extracting version information from git describe...

-- Compiler Version: arm-oe-linux-gnueabi-gcc (GCC) 4.9.2

Copyright (C) 2014 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for

Cross compile gnuradio in E312 error

Dear friends:

     I'm installing rfnoc on E312, when I cross compile gnu radio, I execute this command：cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../

 It prompts the following error：

zcm@zcm-XPS-8500:~/rfnoc/src/gnuradio/build-arm$ cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../

-- Build type not specified: defaulting to release.

-- Build type set to Release.

-- Extracting version information from git describe...

-- Compiler Version: arm-oe-linux-gnueabi-gcc (GCC) 4.9.2

Copyright (C) 2014 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for

Re: Packet Loopback Example Using USRP

That makes sense. Thank you so much for all of your help!! It's much appreciated and has helped me understand what's going on a lot better as well.

On Sun, Jan 24, 2021 at 4:59 PM Jeff Long <willcode4@gmail.com> wrote:

You're not seeing anything on the gui sinks because they only show you periodic snapshots (except for gr-fosphor if you have that installed) and the bursts fall between the snapshots. Inspectrum lets you see every sample in a recorded file.

I'm not going to have time to try out the RX part, but make sure the RF path is sane (attentuators, levels, verify using a File Sink or other method) and then build up the RX one piece at a time. You may have to learn about the internals of packet_rx, and use various debug blocks/gui sinks to figure out what's going on. GRC makes it look like you can drag-and-drop and make a radio.

On Sun, Jan 24, 2021 at 6:39 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Okay, so do the bursts of digital data mean that the USRP Sink is able to successfully get the packet as input and transmit it? 

If so, when I run the packet_usrp.grc flowgraph, why do I not see the USRP Source receive anything? For example, the graphs that represent the USRP Source's output never change. I would expect it to change when it receives a packet of data. Also, if the USRP source was receiving something, wouldn't the Packet RX block decode the packet and print the contents to the terminal using the Message Debug block?

On Sun, Jan 24, 2021 at 2:04 PM Jeff Long <willcode4@gmail.com> wrote:

Yes, that shows bursts of digital data, which is what your tx produces. Use a smaller FFT size to see more detail in the time domain.

On Sun, Jan 24, 2021 at 4:44 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

So, from my understanding you added a File Sink that took in the USRP Source's output to the packet_usrp_tx.grc flowgraph? I tried to recreate what you did and opened the file with Inspectrum and a screenshot of the results is attached. I'm not sure if this is what you got, or what it means. I may be saving it to the File Sink incorrectly, so I attached a screenshot of the File Sink parameters as well. 

Also, what do you mean by 'What happens if you ignore this and keep working' ? Because if I run the packet_usrp.grc flowgraph for a while and ignore the U's printing out, it doesn't give me the result that I expect. The result that I expect would be similar to the result when running the packet_loopback_hier.grc file. 

Thanks again for your continued help!

On Sun, Jan 24, 2021 at 12:03 PM Jeff Long <willcode4@gmail.com> wrote:

Best I can tell (recording raw samples from the USRP Source to a File Sink, then viewing it with inspectrum), it works and the single 'U' per burst is spurious. The docs would lead you to believe you shouldn't see this. Nothing stands out as wrong in the GRCs. What happens if you ignore this and keep working?

On Sun, Jan 24, 2021 at 1:41 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Okay, thanks for the tip. Attached in this email is a flowgraph that only does TX (packet_usrp_tx.grc). I'll continue to look into the problem and see if I can find any solutions myself as well, but again I'm pretty new to GNURadio and USRP. If anyone can help me figure out the problem, it'd be greatly appreciated!! I've also attached the packet loopback example using the USRP with both TX and RX (packet_usrp.grc), the original packet loopback example without USRP (packet_loopback_hier.grc), and the packet_tx and packet_rx flowgraphs as well. 

On Sat, Jan 23, 2021 at 4:36 AM Jeff Long <willcode4@gmail.com> wrote:

Recommend you find the simplest flowgraph that demonstrates this problem. For example, do TX only. Once you find that minimal case, post the actual GRC file somewhere so someone can try it out. It's really difficult to look through a bunch of parameters in a screenshot and try to guess what's happening, unless it's something really obvious.

On Fri, Jan 22, 2021 at 9:24 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Hi again, I have a previous message thread regarding this problem, but I kept forgetting to 'reply all' to include the GNURadio email to keep it on the thread and my questions got kind of disorganized, so I wanted to start fresh with a new one and will make sure to reply all in the future. 

So, I found a packet_loopback example (under the directory: examples/digital/packet) from this message thread and it says that I can replace the Channel Model block with the USRP source and sink blocks to try to send packets over the air (a screenshot of the original packet_loopback example and my modified packet_loopback example is attached as well). This is exactly what I want to do, but I'm running into some issues with the USRP sink. 

I believe the problem has to do with the way that the USRP sink is receiving the packets. I believe it deals with 'bursty transmission', and so I specified the USRP sink's 'TSB tag name' parameter to 'packet_len', which is what the packet_tx block specifies as the length tag name (I've also attached a screenshot of the packet_tx flowgraph). I confirmed that the tag name is 'packet_len' by using the Tag Debug block. 

Also, I've attached a video link here of what happens when I run the program. It seems like the USRP receives the packet here and there because of the short 'bursts' shown on the middle graph. Also, I noticed that there's a 'tG' printed in the terminal window (a screenshot of this is attached as well) when the program is first run. What does this mean? I also know that it's experiencing a lot of underruns, which is essentially the problem I'm trying to solve. It must do with the way the USRP sink is configured to receive the packets. 

Are there any other parameters that need to be set? 

Thanks so much in advance!! I appreciate any help :)