Re: creating a 57 KHz signal from 19 KHz reference
Hi Kristoff
I already tried this in the past but did not saved the
corresponding grc file. I remember thath I did not succeed in
getting a non rotating constellation for the RDS signal which
normally is achieved when using your method. I also tried to
demodulate L-R using the square of the 19Khz pilot (in the
original GRC example, L+R demodulated signal has wrong phase and
wrong amplitude so that is it not possible to recover L or R audio
channel)
In fact cos3(x)= {cos(3x)+3cos(x)}/4 which after
filtering lead to cos(3x)/4
However, in our case the 19KHz pilot amplitude (a) is very low so
that when cubing (a cos(x))3
You get (a cos(x))3=a3 {cos(3x)+3cos(x)}/4
which can be close to noise level
Normally, even if your 57Khz is low, it should be there.
Can you provide your grc file for further investigation?
Regards, Christophe
On 14/11/2019 23:39, Kristoff wrote:
Hi all,
I'm again experimenting with GNUradio, now with a flowgraph I
found ("rds_rx") to demodulate FM/RDS.
One facts about FM/RDS:
After demodulation a FM broadcasting signal, the signal contains
multiple sub-signals, (among others) a 19 KHz 'stereo pilot' and a
PSK (RDS) signal at 57 KHz.
57 KHz is three times 19 KHz.
Question:
I am trying to find a way to use the 19 KHz stereo-pilot signal to
create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57
KHz).
How do I do this?
I tried using a PLL carrier-tracking block to extract the 19 KHz
carrier (which seams to work) and direct that carrier to a 3 input
multiplier block, but that does not seams to work.
Even after filtering out DC and the carrier at -19 KHz (negative
frequency), the output of the multiplier is always zero. (*)
Or is there a better way to generate a 57 KHz complex sine-wave
from a 19 KHz reference signal?
(*)
When I just connect the output of a signal-source block (that
contains a 19 KHz complex-number signal) and connect this to all
ports of a 3-input multiplier, I do get a carrier at 57 KHz.
So I am puzzled why this seams to work, but using the same
technique to multiply the output of a PLL carrier-tracking block
does not result in anything useful.
Cheerio! Kr, Bonne,
Re: How to tell whether gnuradio is using NEON or not?
Going back to this problem, I recently set up a fresh Raspberry Pi 4 system using Ubuntu Server 19.10 and compiled GNU Radio v3.7.13.5 from source, which also compiled the built in Volk. I then ran volk_profile and was surprised to find that the generic machine was very often faster than NEON, and that most of the entries in volk_config preferred the generic machine. This seems incorrect - what could the mistake be? == Here are the build settings: ubuntu@ubuntu:~$ uname -a Linux ubuntu 5.3.0-1012-raspi2 #14-Ubuntu SMP Mon Nov 11 10:06:55 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux ubuntu@ubuntu:~$ volk-config-info --version 2.0 ubuntu@ubuntu:~$ volk-config-info --cc cc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 ubuntu@ubuntu:~$ volk-config-info --cflags /usr/bin/cc:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall generic_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall neon_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -funsafe-math-optimizations neonv8:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -funsafe-math-optimizations -funsafe-math-optimizations ubuntu@ubuntu:~$ volk-config-info --avail-machines generic_orc;neon_orc;neonv8; volk-config-info --machine neon_orc == Here's the output of volk_profile: ubuntu@ubuntu:~$ volk_profile RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) generic completed in 1312.04 ms neon completed in 1378.97 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) generic completed in 1292.81 ms neon completed in 1390.73 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) generic completed in 1311.04 ms neon completed in 1397.88 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_16u_byteswappuppet_16u(131071,1987) generic completed in 224.223 ms neon completed in 278.588 ms neon_table completed in 359.529 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_32u_byteswappuppet_32u(131071,1987) generic completed in 425.049 ms neon completed in 752.16 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_32u_popcntpuppet_32u(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_64u_byteswappuppet_64u(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc(131071,1987) generic completed in 2390.53 ms neon completed in 927.447 ms Best aligned arch: neon Best unaligned arch: neon RUN_VOLK_TESTS: volk_8u_conv_k7_r2puppet_8u(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_32f_x2_fm_detectpuppet_32f(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i(131071,1987) generic completed in 118.046 ms neon completed in 108.788 ms u_orc completed in 133.196 ms Best aligned arch: neon Best unaligned arch: neon RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2(131071,1987) generic completed in 279.341 ms u_orc completed in 625.402 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2(131071,1987) generic completed in 602.508 ms neon completed in 611.587 ms u_orc completed in 5000.92 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_16ic_magnitude_16i(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f(131071,1987) no architectures to test RUN_VOLK_TESTS: volk_16ic_convert_32fc(131071,1987) generic completed in 599.708 ms neon completed in 604.177 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_16ic_x2_multiply_16ic(131071,1987) generic completed in 498.56 ms neon completed in 679.4 ms Best aligned arch: generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_16ic_x2_dot_prod_16ic(131071,1987) generic completed in 1834.92 ms neon completed in 501 ms neon_vma completed in 493.526 ms neon_optvma completed in 463.412 ms Best aligned arch: neon_optvma Best unaligned arch: neon_optvma RUN_VOLK_TESTS: volk_16i_s32f_convert_32f(131071,1987) generic completed in 293.52 ms neon completed in 298.105 ms a_generic completed in 292.449 ms Best aligned arch: a_generic Best unaligned arch: generic RUN_VOLK_TESTS: volk_16i_convert_8i(131071,1987) generic completed in 73.3278 ms neon completed in 68.9267 ms a_generic completed in 71.4697 ms Best aligned arch: neon Best unaligned arch: neon RUN_VOLK_TESTS: volk_16i_3
Re: How to tell whether gnuradio is using NEON or not?
Hi Amr, that just either means that the kernel has no NEON implementation so far, so generic is the only choice, or, and that's *good* news, the compiler has gotten so smart that it outranks hand-written code. Best regards, Marcus On Fri, 2019-11-15 at 14:01 +0300, Amr Bekhit wrote: > Going back to this problem, I recently set up a fresh Raspberry Pi 4 > system using Ubuntu Server 19.10 and compiled GNU Radio v3.7.13.5 from > source, which also compiled the built in Volk. I then ran volk_profile > and was surprised to find that the generic machine was very often > faster than NEON, and that most of the entries in volk_config > preferred the generic machine. This seems incorrect - what could the > mistake be? > > == > Here are the build settings: > > ubuntu@ubuntu:~$ uname -a > Linux ubuntu 5.3.0-1012-raspi2 #14-Ubuntu SMP Mon Nov 11 10:06:55 UTC > 2019 aarch64 aarch64 aarch64 GNU/Linux > > ubuntu@ubuntu:~$ volk-config-info --version > 2.0 > > ubuntu@ubuntu:~$ volk-config-info --cc > cc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 > > ubuntu@ubuntu:~$ volk-config-info --cflags > /usr/bin/cc:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall > -Wno-uninitialized -Wall > generic_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > neon_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > -funsafe-math-optimizations > neonv8:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > -funsafe-math-optimizations -funsafe-math-optimizations > > ubuntu@ubuntu:~$ volk-config-info --avail-machines > generic_orc;neon_orc;neonv8; > > volk-config-info --machine > neon_orc > > == > Here's the output of volk_profile: > > ubuntu@ubuntu:~$ volk_profile > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > generic completed in 1312.04 ms > neon completed in 1378.97 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > generic completed in 1292.81 ms > neon completed in 1390.73 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > generic completed in 1311.04 ms > neon completed in 1397.88 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16u_byteswappuppet_16u(131071,1987) > generic completed in 224.223 ms > neon completed in 278.588 ms > neon_table completed in 359.529 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_32u_byteswappuppet_32u(131071,1987) > generic completed in 425.049 ms > neon completed in 752.16 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_32u_popcntpuppet_32u(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_64u_byteswappuppet_64u(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc(131071,1987) > generic completed in 2390.53 ms > neon completed in 927.447 ms > Best aligned arch: neon > Best unaligned arch: neon > RUN_VOLK_TESTS: volk_8u_conv_k7_r2puppet_8u(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_32f_x2_fm_detectpuppet_32f(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i(131071,1987) > generic completed in 118.046 ms > neon completed in 108.788 ms > u_orc completed in 133.196 ms > Best aligned arch: neon > Best unaligned arch: neon > RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2(131071,1987) > generic completed in 279.341 ms > u_orc completed in 625.402 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2(131071,1987) > generic completed in 602.508 ms > neon completed in 611.587 ms > u_orc completed in 5000.92 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_magnitude_16i(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_convert_32fc(131071,1987) > generic completed in 599.708 ms > neon completed in 604.177 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_x2_multiply_16ic(131071,1987) > generic completed in 498.56 ms > neon completed in 679.4 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_x2_dot_prod_16ic(131071,1987) > generic completed in 1834.92 ms > neon completed in 501 ms > neon_vma completed in 493.5
Re: Baseband signal generating.
Hi Your amplitude is set in constellation object, in the constellation points list. At present yours is +-1 for BPSK, and +-1+-j for QPSK So amplitude is 1 (+-1) for BPSK and 1.414 for QPSK This must be adjusted to your requirements (-0.5,0.5) for BPSK Regards On 15/11/2019 11:03, Md. Atiqur Rahman wrote: Hello there, I am working on generating a baseband signal by using GNU-Radio. I have chosen a random signal along with the constellation modulator and constellation object. However, I go through all settings for these blocks but don't find the setting option for signal 'Amplitude'. How can I be sure that my generating amplitude (let say peak to peak)? I can see the signal amplitude in QT GUI Time Sink but I am not sure how its amplitude define here in this scheme. It seems like signal amplitude is 2v peak to peak. Is it right? But I want to generate a baseband signal which will have 1v peak to peak. Thank you. -- Sincerely, Hasan
Re: Baseband signal generating.
… and the easiest way to adjust that is by simply multiplying the result with the appropriate factor Best regards, Marcus On Fri, 2019-11-15 at 13:06 +0100, Christophe Seguinot wrote: > Hi > > Your amplitude is set in constellation object, in the constellation points > list. > > At present yours is +-1 for BPSK, and +-1+-j for QPSK > > So amplitude is 1 (+-1) for BPSK and 1.414 for QPSK > > This must be adjusted to your requirements (-0.5,0.5) for BPSK > > Regards > > > > On 15/11/2019 11:03, Md. Atiqur Rahman wrote: > > Hello there, I am working on generating a baseband signal by using > > GNU-Radio. I have chosen a random signal along with the constellation > > modulator and constellation object. However, I go through all settings for > > these blocks but don't find the setting option for signal 'Amplitude'. How > > can I be sure that my generating amplitude (let say peak to peak)? > > > > I can see the signal amplitude in QT GUI Time Sink but I am not sure how > > its amplitude define here in this scheme. It seems like signal amplitude is > > 2v peak to peak. Is it right? But I want to generate a baseband signal > > which will have 1v peak to peak. Thank you. > > > > -- > > Sincerely, > > Hasan > > smime.p7s Description: S/MIME cryptographic signature
Re: Baseband signal generating.
Hello, Thank you so much for your response. Yes, I get it. I did multiply the result with the factor but I wanted to know how the constellation object setting defined it. Now I know that, thanks to Mr. Christophe and Mr. Marcus. On Fri, Nov 15, 2019 at 1:20 PM Müller, Marcus (CEL) wrote: > … and the easiest way to adjust that is by simply multiplying the > result with the appropriate factor > > Best regards, > Marcus > On Fri, 2019-11-15 at 13:06 +0100, Christophe Seguinot wrote: > > Hi > > > > Your amplitude is set in constellation object, in the constellation > points list. > > > > At present yours is +-1 for BPSK, and +-1+-j for QPSK > > > > So amplitude is 1 (+-1) for BPSK and 1.414 for QPSK > > > > This must be adjusted to your requirements (-0.5,0.5) for BPSK > > > > Regards > > > > > > > > On 15/11/2019 11:03, Md. Atiqur Rahman wrote: > > > Hello there, I am working on generating a baseband signal by using > GNU-Radio. I have chosen a random signal along with the constellation > modulator and constellation object. However, I go through all settings for > these blocks but don't find the setting option for signal 'Amplitude'. How > can I be sure that my generating amplitude (let say peak to peak)? > > > > > > I can see the signal amplitude in QT GUI Time Sink but I am not sure > how its amplitude define here in this scheme. It seems like signal > amplitude is 2v peak to peak. Is it right? But I want to generate a > baseband signal which will have 1v peak to peak. Thank you. > > > > > > -- > > > Sincerely, > > > Hasan > > > > -- Sincerely, Md Atiqur Rahman Hochschule Bremen
PlutoSDR & Mac - iio block issues??
New here and new to gnuRadio... I'm attempting to get plutoSDR up and running on a Mac, I've installed gunradio and dependencies, I've also downloaded and built libiio, ibad9361-iio and gr-iio. Following this I've moved the block files across to the working directory. Running gnuradio-companion I can see the plutoSDR source & sink blocks, but when using them I get the following error: Traceback (most recent call last): File "/Users/m0khz/Desktop/top_block.py", line 22, in from gnuradio import iio ImportError: cannot import name iio any help in where I'm going wrong much appreciated Cheers Kevin Full build details below: I*nstall GNU Radio* Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio ---> Computing dependencies for gnuradio ---> Cleaning gnuradio ---> Scanning binaries for linking errors ---> No broken files found. ---> No broken ports found. Kevins-MacBook-Pro:~ m0khz$ Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version 3.7.13.5 *Download and build libiio* Kevins-MacBook-Pro:~ m0khz$ cd libiio Kevins-MacBook-Pro:libiio m0khz$ cmake . -- Looking for libusb-1.0 : Found -- Check for case-sensitive file systems -- File system is not case-sensitive -- Configuring done -- Generating done -- Build files have been written to: /Users/m0khz/libiio Kevins-MacBook-Pro:libiio m0khz$ make [ 48%] Built target iio [ 55%] Built target iio_genxml [ 62%] Built target iio_adi_xflow_check [ 68%] Built target iio_reg [ 75%] Built target iio_readdev [ 82%] Built target iio_writedev [ 89%] Built target iio_attr [ 96%] Built target iio_info [100%] Built target libiio-pkg [100%] Built target libiio-py Kevins-MacBook-Pro:libiio m0khz$ sudo make install [ 48%] Built target iio [ 55%] Built target iio_genxml [ 62%] Built target iio_adi_xflow_check [ 68%] Built target iio_reg [ 75%] Built target iio_readdev [ 82%] Built target iio_writedev [ 89%] Built target iio_attr [ 96%] Built target iio_info [100%] Built target libiio-pkg [100%] Built target libiio-py Install the project... -- Install configuration: "RelWithDebInfo" installer: Package name is Libiio installer: Upgrading at base path / installer: The upgrade was successful. Kevins-MacBook-Pro:libiio m0khz$ cd .. Kevins-MacBook-Pro:~ m0khz$ *Download and build libad9361-iio* Kevins-MacBook-Pro:~ m0khz$ cd libad9361-iio Kevins-MacBook-Pro:libad9361-iio m0khz$ cmake . -- Configuring done -- Generating done -- Build files have been written to: /Users/m0khz/libad9361-iio Kevins-MacBook-Pro:libad9361-iio m0khz$ make [ 50%] Built target ad9361 [ 54%] Built target libad9361-pkg [ 63%] Built target AutoRateTest [ 72%] Built target FilterDesignerTest [ 81%] Built target FMComms5SyncTest [ 90%] Built target FilterDesignerHardwareTest [100%] Built target GenerateRatesTest Kevins-MacBook-Pro:libad9361-iio m0khz$ sudo make install [ 50%] Built target ad9361 [ 54%] Built target libad9361-pkg [ 63%] Built target AutoRateTest [ 72%] Built target FilterDesignerTest [ 81%] Built target FMComms5SyncTest [ 90%] Built target FilterDesignerHardwareTest [100%] Built target GenerateRatesTest Install the project... -- Install configuration: "" -- Up-to-date: /usr/local/lib/pkgconfig/libad9361.pc installer: Package name is Libad9361 installer: Upgrading at base path / installer: The upgrade was successful. -- Up-to-date: /usr/local/include/ad9361-wrapper.h Kevins-MacBook-Pro:libad9361-iio m0khz$ cd .. Kevins-MacBook-Pro:~ m0khz$ *Download and build gr-iio* Kevins-MacBook-Pro:~ m0khz$ cd gr-iio Kevins-MacBook-Pro:gr-iio m0khz$ cmake . -- Build type not specified: defaulting to release. Checking for GNU Radio Module: RUNTIME * INCLUDES=/opt/local/include * LIBS=/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib GNURADIO_RUNTIME_FOUND = TRUE Checking for GNU Radio Module: ANALOG * INCLUDES=/opt/local/include * LIBS=/opt/local/lib/libgnuradio-analog.dylib;/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib;/opt/local/lib/libvolk.dylib GNURADIO_ANALOG_FOUND = TRUE Checking for GNU Radio Module: BLOCKS * INCLUDES=/opt/local/include * LIBS=/opt/local/lib/libgnuradio-blocks.dylib;/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib GNURADIO_BLOCKS_FOUND = TRUE Checking for GNU Radio Module: PMT * INCLUDES=/opt/local/include * LIBS=/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib GNURADIO_PMT_FOUND = TRUE Checking for GNU Radio Module: VOLK * INCLUDES=/opt/local/include * LIBS=/opt/local/lib/libvolk.dylib GNURADIO_VOLK_FOUND = TRUE -- -- Checking for module SWIG -- Found SWIG version 3.0.12. -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning.
Re: PlutoSDR & Mac - iio block issues??
Hi Kevin, I’ve run into this too. The instructions tell you the solution after the build commands change the “cmake” line to cmake -DCMAKE_INSTALL_PREFIX=/usr . and rebuild all and do the copy step they suggest on site https://wiki.analog.com/resources/tools-software/linux-software/gnuradio (Either cp -r /usr/local/lib/python2.7/dist-packages/gnuradio/iio /usr/lib/python2.7/dist-packages/gnuradio/ or cp -r /usr/local/lib/python2.7/site-packages/gnuradio/iio /usr/lib/python2.7/site-packages/gnuradio/ or some similar combination, depending on where your build files end up after install ) Good luck. Glen The packages can go into 4 different directories (on Ubuntu, maybe only 2 on mac) /usr/local/lib/python2.7/site-packages /usr/lib/python2.7/site-packages and /usr/local/lib/python2.7/dist-packages /usr/lib/python2.7/dist-packages on Ubuntu I’ve been copying all of the "site-packages" stuff into “dist-packages” and creating symbolic link from dist-packages to site-packages. (Not really recommended, but I do it anyway). Good Luck > On Nov 15, 2019, at 8:11 AM, Kevin Wheatley wrote: > > New here and new to gnuRadio... > > I'm attempting to get plutoSDR up and running on a Mac, I've installed > gunradio and dependencies, I've also downloaded and built libiio, > ibad9361-iio and gr-iio. Following this I've moved the block files across to > the working directory. Running gnuradio-companion > I can see the plutoSDR source & sink blocks, but when using them I get the > following error: > > Traceback (most recent call last): > File "/Users/m0khz/Desktop/top_block.py", line 22, in > from gnuradio import iio > ImportError: cannot import name iio > > any help in where I'm going wrong much appreciated > > Cheers Kevin > > Full build details below: > Install GNU Radio > > Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio > ---> Computing dependencies for gnuradio > ---> Cleaning gnuradio > ---> Scanning binaries for linking errors > ---> No broken files found. > ---> No broken ports found. > Kevins-MacBook-Pro:~ m0khz$ > Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version > 3.7.13.5 > > Download and build libiio > > Kevins-MacBook-Pro:~ m0khz$ cd libiio > Kevins-MacBook-Pro:libiio m0khz$ cmake . > -- Looking for libusb-1.0 : Found > -- Check for case-sensitive file systems > -- File system is not case-sensitive > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/m0khz/libiio > Kevins-MacBook-Pro:libiio m0khz$ make > [ 48%] Built target iio > [ 55%] Built target iio_genxml > [ 62%] Built target iio_adi_xflow_check > [ 68%] Built target iio_reg > [ 75%] Built target iio_readdev > [ 82%] Built target iio_writedev > [ 89%] Built target iio_attr > [ 96%] Built target iio_info > [100%] Built target libiio-pkg > [100%] Built target libiio-py > Kevins-MacBook-Pro:libiio m0khz$ sudo make install > [ 48%] Built target iio > [ 55%] Built target iio_genxml > [ 62%] Built target iio_adi_xflow_check > [ 68%] Built target iio_reg > [ 75%] Built target iio_readdev > [ 82%] Built target iio_writedev > [ 89%] Built target iio_attr > [ 96%] Built target iio_info > [100%] Built target libiio-pkg > [100%] Built target libiio-py > Install the project... > -- Install configuration: "RelWithDebInfo" > installer: Package name is Libiio > installer: Upgrading at base path / > installer: The upgrade was successful. > Kevins-MacBook-Pro:libiio m0khz$ cd .. > Kevins-MacBook-Pro:~ m0khz$ > > Download and build libad9361-iio > > Kevins-MacBook-Pro:~ m0khz$ cd libad9361-iio > Kevins-MacBook-Pro:libad9361-iio m0khz$ cmake . > -- Configuring done > -- Generating done > -- Build files have been written to: /Users/m0khz/libad9361-iio > Kevins-MacBook-Pro:libad9361-iio m0khz$ make > [ 50%] Built target ad9361 > [ 54%] Built target libad9361-pkg > [ 63%] Built target AutoRateTest > [ 72%] Built target FilterDesignerTest > [ 81%] Built target FMComms5SyncTest > [ 90%] Built target FilterDesignerHardwareTest > [100%] Built target GenerateRatesTest > Kevins-MacBook-Pro:libad9361-iio m0khz$ sudo make install > [ 50%] Built target ad9361 > [ 54%] Built target libad9361-pkg > [ 63%] Built target AutoRateTest > [ 72%] Built target FilterDesignerTest > [ 81%] Built target FMComms5SyncTest > [ 90%] Built target FilterDesignerHardwareTest > [100%] Built target GenerateRatesTest > Install the project... > -- Install configuration: "" > -- Up-to-date: /usr/local/lib/pkgconfig/libad9361.pc > installer: Package name is Libad9361 > installer: Upgrading at base path / > installer: The upgrade was successful. > -- Up-to-date: /usr/local/include/ad9361-wrapper.h > Kevins-MacBook-Pro:libad9361-iio m0khz$ cd .. > Kevins-MacBook-Pro:~ m0khz$ > > Download and build gr-iio > > Kevins-MacBook-Pro:~ m0khz$ cd gr-iio > Kevins-MacBook-Pro:gr-iio m0khz$ cmake . > -- Build type not specified: defaulting to release. > Checking for GNU Radio Module: R
Re: PlutoSDR & Mac - iio block issues??
Hi Kevin, See also https://github.com/gnuradio/gnuradio/pull/2781 Emmanuel On 15 Nov 2019, at 14:41, Glen I Langston wrote: Hi Kevin, I’ve run into this too. The instructions tell you the solution after the build commands change the “cmake” line to cmake -DCMAKE_INSTALL_PREFIX=/usr . and rebuild all and do the copy step they suggest on site https://wiki.analog.com/resources/tools-software/linux-software/gnuradio (Either cp -r /usr/local/lib/python2.7/dist-packages/gnuradio/iio /usr/lib/python2.7/dist-packages/gnuradio/ or cp -r /usr/local/lib/python2.7/site-packages/gnuradio/iio /usr/lib/python2.7/site-packages/gnuradio/ or some similar combination, depending on where your build files end up after install ) Good luck. Glen The packages can go into 4 different directories (on Ubuntu, maybe only 2 on mac) /usr/local/lib/python2.7/site-packages /usr/lib/python2.7/site-packages and /usr/local/lib/python2.7/dist-packages /usr/lib/python2.7/dist-packages on Ubuntu I’ve been copying all of the "site-packages" stuff into “dist-packages” and creating symbolic link from dist-packages to site-packages. (Not really recommended, but I do it anyway). Good Luck On Nov 15, 2019, at 8:11 AM, Kevin Wheatley wrote: New here and new to gnuRadio... I'm attempting to get plutoSDR up and running on a Mac, I've installed gunradio and dependencies, I've also downloaded and built libiio, ibad9361-iio and gr-iio. Following this I've moved the block files across to the working directory. Running gnuradio-companion I can see the plutoSDR source & sink blocks, but when using them I get the following error: Traceback (most recent call last): File "/Users/m0khz/Desktop/top_block.py", line 22, in from gnuradio import iio ImportError: cannot import name iio any help in where I'm going wrong much appreciated Cheers Kevin Full build details below: Install GNU Radio Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio ---> Computing dependencies for gnuradio ---> Cleaning gnuradio ---> Scanning binaries for linking errors ---> No broken files found. ---> No broken ports found. Kevins-MacBook-Pro:~ m0khz$ Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version 3.7.13.5 Download and build libiio Kevins-MacBook-Pro:~ m0khz$ cd libiio Kevins-MacBook-Pro:libiio m0khz$ cmake . -- Looking for libusb-1.0 : Found -- Check for case-sensitive file systems -- File system is not case-sensitive -- Configuring done -- Generating done -- Build files have been written to: /Users/m0khz/libiio Kevins-MacBook-Pro:libiio m0khz$ make [ 48%] Built target iio [ 55%] Built target iio_genxml [ 62%] Built target iio_adi_xflow_check [ 68%] Built target iio_reg [ 75%] Built target iio_readdev [ 82%] Built target iio_writedev [ 89%] Built target iio_attr [ 96%] Built target iio_info [100%] Built target libiio-pkg [100%] Built target libiio-py Kevins-MacBook-Pro:libiio m0khz$ sudo make install [ 48%] Built target iio [ 55%] Built target iio_genxml [ 62%] Built target iio_adi_xflow_check [ 68%] Built target iio_reg [ 75%] Built target iio_readdev [ 82%] Built target iio_writedev [ 89%] Built target iio_attr [ 96%] Built target iio_info [100%] Built target libiio-pkg [100%] Built target libiio-py Install the project... -- Install configuration: "RelWithDebInfo" installer: Package name is Libiio installer: Upgrading at base path / installer: The upgrade was successful. Kevins-MacBook-Pro:libiio m0khz$ cd .. Kevins-MacBook-Pro:~ m0khz$ Download and build libad9361-iio Kevins-MacBook-Pro:~ m0khz$ cd libad9361-iio Kevins-MacBook-Pro:libad9361-iio m0khz$ cmake . -- Configuring done -- Generating done -- Build files have been written to: /Users/m0khz/libad9361-iio Kevins-MacBook-Pro:libad9361-iio m0khz$ make [ 50%] Built target ad9361 [ 54%] Built target libad9361-pkg [ 63%] Built target AutoRateTest [ 72%] Built target FilterDesignerTest [ 81%] Built target FMComms5SyncTest [ 90%] Built target FilterDesignerHardwareTest [100%] Built target GenerateRatesTest Kevins-MacBook-Pro:libad9361-iio m0khz$ sudo make install [ 50%] Built target ad9361 [ 54%] Built target libad9361-pkg [ 63%] Built target AutoRateTest [ 72%] Built target FilterDesignerTest [ 81%] Built target FMComms5SyncTest [ 90%] Built target FilterDesignerHardwareTest [100%] Built target GenerateRatesTest Install the project... -- Install configuration: "" -- Up-to-date: /usr/local/lib/pkgconfig/libad9361.pc installer: Package name is Libad9361 installer: Upgrading at base path / installer: The upgrade was successful. -- Up-to-date: /usr/local/include/ad9361-wrapper.h Kevins-MacBook-Pro:libad9361-iio m0khz$ cd .. Kevins-MacBook-Pro:~ m0khz$ Download and build gr-iio Kevins-MacBook-Pro:~ m0khz$ cd gr-iio Kevins-MacBook-Pro:gr-iio m0khz$ cmake . -- Build type not specified: defaulting to release. Checking for GNU Radio Module: RUNTIME * INCLUDES=/opt/local/include * LIBS=/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dyl
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Thank for your help Chris, I have now gotten the SDRPlay connected to my telescope and the results are looking reasonable. My initial problems were with the sense of the gain values, which are actually attenuation values for the SDRPlay. It seems like the defaults are reasonable, and that probably the correct band pass filter is being chosen for the observing frequency of 1420.4 MHz. I still do not fully know what the LNA slider value does. FYI the initial interfering lines seem to have gone away after I got sufficiently strong signals into the SDRPlay. Best regards Glen > On Nov 14, 2019, at 2:57 PM, Chris Vine wrote: > > On Thu, 14 Nov 2019 19:35:13 + > Chris Vine wrote: >> The original poster can get some information from installing soapy and >> doing 'SoapySDRUtil --probe'. > > I should probably have appended what the probe tells me about my RSP1A, > which may or may not apply to his: > > > -- Device identification > > driver=SDRplay > hardware=RSP1A > mir_sdr_api_version=2.13 > mir_sdr_hw_version=255 > serial=xxx > > > -- Peripheral summary > > Channels: 1 Rx, 0 Tx > Timestamps: NO > Other Settings: > * RF Gain Select - RF Gain Select > [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, > 7, 8, 9)] > * IF Mode - IF frequency in kHz > [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, > 1620kHz, 2048kHz)] > * IQ Correction - IQ Correction Control > [key=iqcorr_ctrl, default=true, type=bool] > * AGC Setpoint - AGC Setpoint (dBfs) > [key=agc_setpoint, default=-30, type=int, range=[-60, 0]] > * BiasT Enable - BiasT Control > [key=biasT_ctrl, default=true, type=bool] > * RfNotch Enable - RF Notch Filter Control > [key=rfnotch_ctrl, default=true, type=bool] > * DabNotch Enable - DAB Notch Filter Control > [key=dabnotch_ctrl, default=true, type=bool] > > > -- RX Channel 0 > > Full-duplex: NO > Supports AGC: YES > Stream formats: CS16, CF32 > Native format: CS16 [full-scale=32767] > Antennas: RX > Corrections: DC removal > Full gain range: [0, 48] dB >IFGR gain range: [20, 59] dB >RFGR gain range: [0, 9] dB > Full freq range: [0.01, 2000] MHz >RF freq range: [0.01, 2000] MHz >CORR freq range: MHz > Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps > Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz >
Re: PlutoSDR & Mac - iio block issues??
You need to set
{{{
PYTHONPATH=/usr/local/lib/python2.7/site-packages/:$PYTHONPATH
}}}
to get access to gr-iio.
On Fri, Nov 15, 2019 at 8:17 AM Kevin Wheatley
wrote:
> New here and new to gnuRadio...
>
> I'm attempting to get plutoSDR up and running on a Mac, I've installed
> gunradio and dependencies, I've also downloaded and built libiio,
> ibad9361-iio and gr-iio. Following this I've moved the block files across
> to the working directory. Running gnuradio-companion
> I can see the plutoSDR source & sink blocks, but when using them I get the
> following error:
>
> Traceback (most recent call last):
> File "/Users/m0khz/Desktop/top_block.py", line 22, in
> from gnuradio import iio
> ImportError: cannot import name iio
>
> any help in where I'm going wrong much appreciated
>
> Cheers Kevin
>
> Full build details below:
> I*nstall GNU Radio*
>
> Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio
> ---> Computing dependencies for gnuradio
> ---> Cleaning gnuradio
> ---> Scanning binaries for linking errors
> ---> No broken files found.
> ---> No broken ports found.
> Kevins-MacBook-Pro:~ m0khz$
> Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version
> 3.7.13.5
>
> *Download and build libiio*
>
> Kevins-MacBook-Pro:~ m0khz$ cd libiio
> Kevins-MacBook-Pro:libiio m0khz$ cmake .
> -- Looking for libusb-1.0 : Found
> -- Check for case-sensitive file systems
> -- File system is not case-sensitive
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/m0khz/libiio
> Kevins-MacBook-Pro:libiio m0khz$ make
> [ 48%] Built target iio
> [ 55%] Built target iio_genxml
> [ 62%] Built target iio_adi_xflow_check
> [ 68%] Built target iio_reg
> [ 75%] Built target iio_readdev
> [ 82%] Built target iio_writedev
> [ 89%] Built target iio_attr
> [ 96%] Built target iio_info
> [100%] Built target libiio-pkg
> [100%] Built target libiio-py
> Kevins-MacBook-Pro:libiio m0khz$ sudo make install
> [ 48%] Built target iio
> [ 55%] Built target iio_genxml
> [ 62%] Built target iio_adi_xflow_check
> [ 68%] Built target iio_reg
> [ 75%] Built target iio_readdev
> [ 82%] Built target iio_writedev
> [ 89%] Built target iio_attr
> [ 96%] Built target iio_info
> [100%] Built target libiio-pkg
> [100%] Built target libiio-py
> Install the project...
> -- Install configuration: "RelWithDebInfo"
> installer: Package name is Libiio
> installer: Upgrading at base path /
> installer: The upgrade was successful.
> Kevins-MacBook-Pro:libiio m0khz$ cd ..
> Kevins-MacBook-Pro:~ m0khz$
>
> *Download and build libad9361-iio*
>
> Kevins-MacBook-Pro:~ m0khz$ cd libad9361-iio
> Kevins-MacBook-Pro:libad9361-iio m0khz$ cmake .
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/m0khz/libad9361-iio
> Kevins-MacBook-Pro:libad9361-iio m0khz$ make
> [ 50%] Built target ad9361
> [ 54%] Built target libad9361-pkg
> [ 63%] Built target AutoRateTest
> [ 72%] Built target FilterDesignerTest
> [ 81%] Built target FMComms5SyncTest
> [ 90%] Built target FilterDesignerHardwareTest
> [100%] Built target GenerateRatesTest
> Kevins-MacBook-Pro:libad9361-iio m0khz$ sudo make install
> [ 50%] Built target ad9361
> [ 54%] Built target libad9361-pkg
> [ 63%] Built target AutoRateTest
> [ 72%] Built target FilterDesignerTest
> [ 81%] Built target FMComms5SyncTest
> [ 90%] Built target FilterDesignerHardwareTest
> [100%] Built target GenerateRatesTest
> Install the project...
> -- Install configuration: ""
> -- Up-to-date: /usr/local/lib/pkgconfig/libad9361.pc
> installer: Package name is Libad9361
> installer: Upgrading at base path /
> installer: The upgrade was successful.
> -- Up-to-date: /usr/local/include/ad9361-wrapper.h
> Kevins-MacBook-Pro:libad9361-iio m0khz$ cd ..
> Kevins-MacBook-Pro:~ m0khz$
>
> *Download and build gr-iio*
>
> Kevins-MacBook-Pro:~ m0khz$ cd gr-iio
> Kevins-MacBook-Pro:gr-iio m0khz$ cmake .
> -- Build type not specified: defaulting to release.
> Checking for GNU Radio Module: RUNTIME
> * INCLUDES=/opt/local/include
> *
> LIBS=/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib
> GNURADIO_RUNTIME_FOUND = TRUE
> Checking for GNU Radio Module: ANALOG
> * INCLUDES=/opt/local/include
> *
> LIBS=/opt/local/lib/libgnuradio-analog.dylib;/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib;/opt/local/lib/libvolk.dylib
> GNURADIO_ANALOG_FOUND = TRUE
> Checking for GNU Radio Module: BLOCKS
> * INCLUDES=/opt/local/include
> *
> LIBS=/opt/local/lib/libgnuradio-blocks.dylib;/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib
> GNURADIO_BLOCKS_FOUND = TRUE
> Checking for GNU Radio Module: PMT
> * INCLUDES=/opt/local/include
> *
> LIBS=/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib
> GNURADIO_PMT_FOUND = TRUE
> Checking for GNU
Re: PlutoSDR & Mac - iio block issues??
I -strongly- recommend against setting the CMAKE_INSTALL_PREFIX to a system directory such as /usr when you are building from source (not using a package manager)! You never know what you're going to overwrite from the system itself, which can cause library loading breakage. When installing anything from source, use a "local" directory of some sort ... /usr/local is perfectly fine! Then, set environment variables to find the installed stuff: PATH, PYTHONPATH, PKG_CONFIG_PATH, MANPATH, INFOPATH, etc... That said, on OSX just please don't set DYLD_LIBRARY_PATH except for temporarily for testing purposes; doing so can really mess up application execution! My US$0.02 worth ... - MLD On Fri, Nov 15, 2019 at 8:42 AM Glen I Langston wrote: > Hi Kevin, > > I’ve run into this too. > > The instructions tell you the solution after the build commands > > change the “cmake” line to > cmake -DCMAKE_INSTALL_PREFIX=/usr . > and rebuild all > > and do the copy step they suggest on site > > https://wiki.analog.com/resources/tools-software/linux-software/gnuradio > (Either > cp -r /usr/local/lib/python2.7/dist-packages/gnuradio/iio > /usr/lib/python2.7/dist-packages/gnuradio/ > or > cp -r /usr/local/lib/python2.7/site-packages/gnuradio/iio > /usr/lib/python2.7/site-packages/gnuradio/ > or > some similar combination, depending on where your build files end up after > install > ) > > Good luck. > > Glen > > The packages can go into 4 different directories (on Ubuntu, maybe only 2 > on mac) > > /usr/local/lib/python2.7/site-packages > /usr/lib/python2.7/site-packages > > and > > /usr/local/lib/python2.7/dist-packages > /usr/lib/python2.7/dist-packages > > on Ubuntu > > I’ve been copying all of the "site-packages" stuff into “dist-packages” > and creating symbolic link from dist-packages to site-packages. > > (Not really recommended, but I do it anyway). > > Good Luck > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
Re: PlutoSDR & Mac - iio block issues??
One final reply: You used MacPorts to install GNU Radio ... so why not use
it to install all of the IIO stuff? "port search iio" should come back with:
{{{
gr-iio @20190725-9088ac79_1 (science, comms)
Provides augmented functionality for GNU Radio: IIO device source
libad9361-iio @20190910 (science, comms)
libad9361-iio is an IIO AD9361 library for filter design and handling,
multi-chip sync, and more
libiio @0.18_1 (science, comms)
libiio is used to interface to the Industrial Input/Output (IIO)
Subsystem
libiio-devel @20191104-c9a854f8 (science, comms)
libiio is used to interface to the Industrial Input/Output (IIO)
Subsystem
}}}
The GR ports are for GR37 still; we're working on updating everything to be
installable for GR37 and GR38 ... and, where possible, GR39-beta. - MLD
Re: PlutoSDR & Mac - iio block issues??
Thanks
I’ll try that in the future.
However I’m not sure why this is an issue in the first place. It should
be fixable at the cmake step.
Looking at the link provided in an earlier email, it seems
like part of the problem is the different uses of
site-packages and
dist-packages.
Can that be fixed at the cmake step?
Thanks again,
Glen
> On Nov 15, 2019, at 9:37 AM, Michael Dickens
> wrote:
>
> You need to set
> {{{
> PYTHONPATH=/usr/local/lib/python2.7/site-packages/:$PYTHONPATH
> }}}
> to get access to gr-iio.
>
>
> On Fri, Nov 15, 2019 at 8:17 AM Kevin Wheatley wrote:
> New here and new to gnuRadio...
>
> I'm attempting to get plutoSDR up and running on a Mac, I've installed
> gunradio and dependencies, I've also downloaded and built libiio,
> ibad9361-iio and gr-iio. Following this I've moved the block files across to
> the working directory. Running gnuradio-companion
> I can see the plutoSDR source & sink blocks, but when using them I get the
> following error:
>
> Traceback (most recent call last):
> File "/Users/m0khz/Desktop/top_block.py", line 22, in
> from gnuradio import iio
> ImportError: cannot import name iio
>
> any help in where I'm going wrong much appreciated
>
> Cheers Kevin
>
> Full build details below:
> Install GNU Radio
>
> Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio
> ---> Computing dependencies for gnuradio
> ---> Cleaning gnuradio
> ---> Scanning binaries for linking errors
> ---> No broken files found.
> ---> No broken ports found.
> Kevins-MacBook-Pro:~ m0khz$
> Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version
> 3.7.13.5
>
> Download and build libiio
>
> Kevins-MacBook-Pro:~ m0khz$ cd libiio
> Kevins-MacBook-Pro:libiio m0khz$ cmake .
> -- Looking for libusb-1.0 : Found
> -- Check for case-sensitive file systems
> -- File system is not case-sensitive
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/m0khz/libiio
> Kevins-MacBook-Pro:libiio m0khz$ make
> [ 48%] Built target iio
> [ 55%] Built target iio_genxml
> [ 62%] Built target iio_adi_xflow_check
> [ 68%] Built target iio_reg
> [ 75%] Built target iio_readdev
> [ 82%] Built target iio_writedev
> [ 89%] Built target iio_attr
> [ 96%] Built target iio_info
> [100%] Built target libiio-pkg
> [100%] Built target libiio-py
> Kevins-MacBook-Pro:libiio m0khz$ sudo make install
> [ 48%] Built target iio
> [ 55%] Built target iio_genxml
> [ 62%] Built target iio_adi_xflow_check
> [ 68%] Built target iio_reg
> [ 75%] Built target iio_readdev
> [ 82%] Built target iio_writedev
> [ 89%] Built target iio_attr
> [ 96%] Built target iio_info
> [100%] Built target libiio-pkg
> [100%] Built target libiio-py
> Install the project...
> -- Install configuration: "RelWithDebInfo"
> installer: Package name is Libiio
> installer: Upgrading at base path /
> installer: The upgrade was successful.
> Kevins-MacBook-Pro:libiio m0khz$ cd ..
> Kevins-MacBook-Pro:~ m0khz$
>
> Download and build libad9361-iio
>
> Kevins-MacBook-Pro:~ m0khz$ cd libad9361-iio
> Kevins-MacBook-Pro:libad9361-iio m0khz$ cmake .
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/m0khz/libad9361-iio
> Kevins-MacBook-Pro:libad9361-iio m0khz$ make
> [ 50%] Built target ad9361
> [ 54%] Built target libad9361-pkg
> [ 63%] Built target AutoRateTest
> [ 72%] Built target FilterDesignerTest
> [ 81%] Built target FMComms5SyncTest
> [ 90%] Built target FilterDesignerHardwareTest
> [100%] Built target GenerateRatesTest
> Kevins-MacBook-Pro:libad9361-iio m0khz$ sudo make install
> [ 50%] Built target ad9361
> [ 54%] Built target libad9361-pkg
> [ 63%] Built target AutoRateTest
> [ 72%] Built target FilterDesignerTest
> [ 81%] Built target FMComms5SyncTest
> [ 90%] Built target FilterDesignerHardwareTest
> [100%] Built target GenerateRatesTest
> Install the project...
> -- Install configuration: ""
> -- Up-to-date: /usr/local/lib/pkgconfig/libad9361.pc
> installer: Package name is Libad9361
> installer: Upgrading at base path /
> installer: The upgrade was successful.
> -- Up-to-date: /usr/local/include/ad9361-wrapper.h
> Kevins-MacBook-Pro:libad9361-iio m0khz$ cd ..
> Kevins-MacBook-Pro:~ m0khz$
>
> Download and build gr-iio
>
> Kevins-MacBook-Pro:~ m0khz$ cd gr-iio
> Kevins-MacBook-Pro:gr-iio m0khz$ cmake .
> -- Build type not specified: defaulting to release.
> Checking for GNU Radio Module: RUNTIME
> * INCLUDES=/opt/local/include
> *
> LIBS=/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib
> GNURADIO_RUNTIME_FOUND = TRUE
> Checking for GNU Radio Module: ANALOG
> * INCLUDES=/opt/local/include
> *
> LIBS=/opt/local/lib/libgnuradio-analog.dylib;/opt/local/lib/libgnuradio-runtime.dylib;/opt/local/lib/libgnuradio-pmt.dylib;/opt/local/lib/liblog4cpp.dylib;/opt/local/lib/libvolk.dylib
> GNURADIO_ANALOG_FOUND = TRUE
> Checking for GNU Radio Module: BLOCKS
> * I
Re: PlutoSDR & Mac - iio block issues??
Hi Glen - Yes, all of this can be fixed in the "cmake .." step. That's what
we do in MacPorts to get all of the files installed in the correct
locations (using CMAKE_INSTALL_PREFIX=/opt/local by default; but also using
other cmake variables to set other install locations to be not the default
too, since MacPorts has expectations for where certain files types are
installed). This issue has nothing directly to do with the link provided
about site-packages and dist-packages. It's all about putting PYTHON files
where the version of Python used by GNU Radio will find the GR OOT scripts.
We provide the cmake variable `GR_PYTHON_DIR` for the top-level directory
to install PYTHON files. Generally, GR-proper PYTHON files will be
installed into "`GR_PYTHON_DIR`/gnuradio" ... most GR OOTs install into
"`GR_PYTHON_DIR`/OOT" though I believe gr-osmosdr installs into
"`GR_PYTHON_DIR`/gnuradio/osmosdr" by default (which, to be honest, I
prefer). If you install a GR OOT elsewhere, you can use the PYTHONPATH
environment variable to tell Python where to look for those scripts; this
is what "make test" does, at least nominally, so that we can "test" without
having to "install" first. Hope this is useful! - MLD
On Fri, Nov 15, 2019 at 9:51 AM Glen I Langston
wrote:
> Thanks
> I’ll try that in the future.
> However I’m not sure why this is an issue in the first place. It should
> be fixable at the cmake step.
>
> Looking at the link provided in an earlier email, it seems
> like part of the problem is the different uses of
> site-packages and
> dist-packages.
>
> Can that be fixed at the cmake step?
>
> Thanks again,
> Glen
>
> > On Nov 15, 2019, at 9:37 AM, Michael Dickens
> wrote:
> >
> > You need to set
> > {{{
> > PYTHONPATH=/usr/local/lib/python2.7/site-packages/:$PYTHONPATH
> > }}}
> > to get access to gr-iio.
> >
> >
> > On Fri, Nov 15, 2019 at 8:17 AM Kevin Wheatley
> wrote:
> > New here and new to gnuRadio...
> >
> > I'm attempting to get plutoSDR up and running on a Mac, I've installed
> gunradio and dependencies, I've also downloaded and built libiio,
> ibad9361-iio and gr-iio. Following this I've moved the block files across
> to the working directory. Running gnuradio-companion
> > I can see the plutoSDR source & sink blocks, but when using them I get
> the following error:
> >
> > Traceback (most recent call last):
> > File "/Users/m0khz/Desktop/top_block.py", line 22, in
> > from gnuradio import iio
> > ImportError: cannot import name iio
> >
> > any help in where I'm going wrong much appreciated
> >
> > Cheers Kevin
> >
> > Full build details below:
> > Install GNU Radio
> >
> > Kevins-MacBook-Pro:~ m0khz$ sudo port install gnuradio
> > ---> Computing dependencies for gnuradio
> > ---> Cleaning gnuradio
> > ---> Scanning binaries for linking errors
> > ---> No broken files found.
> > ---> No broken ports found.
> > Kevins-MacBook-Pro:~ m0khz$
> > Kevins-MacBook-Pro:~ m0khz$ gnuradio-config-info --version
> > 3.7.13.5
> >
> > Download and build libiio
> >
> > Kevins-MacBook-Pro:~ m0khz$ cd libiio
> > Kevins-MacBook-Pro:libiio m0khz$ cmake .
> > -- Looking for libusb-1.0 : Found
> > -- Check for case-sensitive file systems
> > -- File system is not case-sensitive
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /Users/m0khz/libiio
> > Kevins-MacBook-Pro:libiio m0khz$ make
> > [ 48%] Built target iio
> > [ 55%] Built target iio_genxml
> > [ 62%] Built target iio_adi_xflow_check
> > [ 68%] Built target iio_reg
> > [ 75%] Built target iio_readdev
> > [ 82%] Built target iio_writedev
> > [ 89%] Built target iio_attr
> > [ 96%] Built target iio_info
> > [100%] Built target libiio-pkg
> > [100%] Built target libiio-py
> > Kevins-MacBook-Pro:libiio m0khz$ sudo make install
> > [ 48%] Built target iio
> > [ 55%] Built target iio_genxml
> > [ 62%] Built target iio_adi_xflow_check
> > [ 68%] Built target iio_reg
> > [ 75%] Built target iio_readdev
> > [ 82%] Built target iio_writedev
> > [ 89%] Built target iio_attr
> > [ 96%] Built target iio_info
> > [100%] Built target libiio-pkg
> > [100%] Built target libiio-py
> > Install the project...
> > -- Install configuration: "RelWithDebInfo"
> > installer: Package name is Libiio
> > installer: Upgrading at base path /
> > installer: The upgrade was successful.
> > Kevins-MacBook-Pro:libiio m0khz$ cd ..
> > Kevins-MacBook-Pro:~ m0khz$
> >
> > Download and build libad9361-iio
> >
> > Kevins-MacBook-Pro:~ m0khz$ cd libad9361-iio
> > Kevins-MacBook-Pro:libad9361-iio m0khz$ cmake .
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /Users/m0khz/libad9361-iio
> > Kevins-MacBook-Pro:libad9361-iio m0khz$ make
> > [ 50%] Built target ad9361
> > [ 54%] Built target libad9361-pkg
> > [ 63%] Built target AutoRateTest
> > [ 72%] Built target FilterDesignerTest
> > [ 81%] Built target FMComms5SyncTest
> > [ 90%] Built target FilterDesignerHardwareTest
> > [100%] Built target GenerateRatesTest
Re: Baseband signal generating.
The 3.7-era constellation encoders, if I remember correctly, are average-power-normalizing. So, as I said, simply multiply by a factor 0.5. You already have that in your flow graph and bypassed it. So, you already know what to do. Go wild! (Also, you usually do *not* want a fixed peak-to-peak amplitude but actually a fixed average power when you want to compare things. Anything else would be unfair!) Best regards, Marcus On Fri, 2019-11-15 at 16:35 +0100, Md. Atiqur Rahman wrote: > Hello, > I did change the constellations point to -0.5,+0.5 but still, the output > signal amplitude is the same as before. > This is for BPSK, what should I do for other schemes if I want to change its > amplitude 1v peak to peak? > Thank you. > smime.p7s Description: S/MIME cryptographic signature
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
On 11/15/2019 09:17 AM, Glen I Langston wrote: Thank for your help Chris, I have now gotten the SDRPlay connected to my telescope and the results are looking reasonable. My initial problems were with the sense of the gain values, which are actually attenuation values for the SDRPlay. It seems like the defaults are reasonable, and that probably the correct band pass filter is being chosen for the observing frequency of 1420.4 MHz. I still do not fully know what the LNA slider value does. FYI the initial interfering lines seem to have gone away after I got sufficiently strong signals into the SDRPlay. Best regards Glen Glen: I'm keen to learn of your progress on this. I bought a couple of the much-cheaper "clones", and I have them working, but haven't tried any astronomy with them yet. Cheers Marcus On Nov 14, 2019, at 2:57 PM, Chris Vine wrote: On Thu, 14 Nov 2019 19:35:13 + Chris Vine wrote: The original poster can get some information from installing soapy and doing 'SoapySDRUtil --probe'. I should probably have appended what the probe tells me about my RSP1A, which may or may not apply to his: -- Device identification driver=SDRplay hardware=RSP1A mir_sdr_api_version=2.13 mir_sdr_hw_version=255 serial=xxx -- Peripheral summary Channels: 1 Rx, 0 Tx Timestamps: NO Other Settings: * RF Gain Select - RF Gain Select [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)] * IF Mode - IF frequency in kHz [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)] * IQ Correction - IQ Correction Control [key=iqcorr_ctrl, default=true, type=bool] * AGC Setpoint - AGC Setpoint (dBfs) [key=agc_setpoint, default=-30, type=int, range=[-60, 0]] * BiasT Enable - BiasT Control [key=biasT_ctrl, default=true, type=bool] * RfNotch Enable - RF Notch Filter Control [key=rfnotch_ctrl, default=true, type=bool] * DabNotch Enable - DAB Notch Filter Control [key=dabnotch_ctrl, default=true, type=bool] -- RX Channel 0 Full-duplex: NO Supports AGC: YES Stream formats: CS16, CF32 Native format: CS16 [full-scale=32767] Antennas: RX Corrections: DC removal Full gain range: [0, 48] dB IFGR gain range: [20, 59] dB RFGR gain range: [0, 9] dB Full freq range: [0.01, 2000] MHz RF freq range: [0.01, 2000] MHz CORR freq range: MHz Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz
Re: creating a 57 KHz signal from 19 KHz reference
> From: Kristoff > Date: Thu, 14 Nov 2019 23:39:32 +0100 [snip] > Question: > > I am trying to find a way to use the 19 KHz stereo-pilot signal to > create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57 > KHz). > > How do I do this? Use the PLL carrier tracking block which will simultaneously: 1) phase lock to the 19 kHz pilot tone 2) shift (in reality rotate) the spectrum of the signal so the 19 kHz tone gets moved to 0 Hz. After that use a Rotator block to shift the spectrum another 38 kHz = 57 kHz - 19 kHz Then use an FIR/FFT filter block with low pass taps to isolate your RDS signal. > > Itried using a PLL carrier-tracking block to extract the 19 KHz > carrier (which seams to work) and direct that carrier to a 3 input > multiplier block, but that does not seams to work. Even after > filtering out DC and the carrier at -19 KHz (negative frequency), > the output of the multiplier is always zero. (*) You have neglected that that PLL block performs a spectrum shift as well as tracking the pilot signal. Put a QT GUI Freq sink on the output of the PLL carrier tracking block to see. > > Or is there a better way to generate a 57 KHz complex sine-wave from > a 19 KHz reference signal? There is no need to have a locally generated 57 kHz carrier, when you can just use a PLL to phase lock and then a rotator to shift the spectrum. -Andy
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Hi Marcus, Two good things about the SDRplay, now that the gnuradio interface seems to be working, are: 1) Very high gain. I need about 30 dB of IF attenuation to get the levels right. 2) Very good data transfer rates. Right now I appear to be getting 100% of the 7 MHz samples delivered to a raspberry Pi 4 and/or Odroid n2. I’ve not yet fully checked the SDRPlay for short term transients. Note that the Pluto SDR has no (or at least few) short term transients in the RF. I did find the AIRSPY did have some transients that seem to be due to the device. These occur a few thousand times a day, but for shorter than 100 micro seconds. Total time on is less than a second a day. I’ll try to do another calibration test. My initial test seemed to show significant gain changes across the 7MHz band, as if I have the wrong filter selected. At one end the Tsys was too low and at the other end the Tsys was too high, with a reasonable value of about 100 K in the middle of the 1420 MHz band. Still trying to figure this out. Best regards Glen > On Nov 15, 2019, at 11:56 AM, Marcus D. Leech wrote: > > On 11/15/2019 09:17 AM, Glen I Langston wrote: >> Thank for your help Chris, >> >> I have now gotten the SDRPlay connected to my telescope >> and the results are looking reasonable. >> >> My initial problems were with the sense of the gain values, which >> are actually attenuation values for the SDRPlay. >> >> It seems like the defaults are reasonable, and that probably >> the correct band pass filter is being chosen for the >> observing frequency of 1420.4 MHz. >> >> I still do not fully know what the LNA slider value does. >> >> FYI the initial interfering lines seem to have gone away after >> I got sufficiently strong signals into the SDRPlay. >> >> Best regards >> >> Glen > Glen: > > I'm keen to learn of your progress on this. I bought a couple of the > much-cheaper "clones", and I have them working, but haven't tried any > astronomy with them yet. > > Cheers > Marcus > >>> On Nov 14, 2019, at 2:57 PM, Chris Vine wrote: >>> >>> On Thu, 14 Nov 2019 19:35:13 + >>> Chris Vine wrote: The original poster can get some information from installing soapy and doing 'SoapySDRUtil --probe'. >>> I should probably have appended what the probe tells me about my RSP1A, >>> which may or may not apply to his: >>> >>> >>> -- Device identification >>> >>> driver=SDRplay >>> hardware=RSP1A >>> mir_sdr_api_version=2.13 >>> mir_sdr_hw_version=255 >>> serial=xxx >>> >>> >>> -- Peripheral summary >>> >>> Channels: 1 Rx, 0 Tx >>> Timestamps: NO >>> Other Settings: >>> * RF Gain Select - RF Gain Select >>> [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, >>> 6, 7, 8, 9)] >>> * IF Mode - IF frequency in kHz >>> [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, >>> 1620kHz, 2048kHz)] >>> * IQ Correction - IQ Correction Control >>> [key=iqcorr_ctrl, default=true, type=bool] >>> * AGC Setpoint - AGC Setpoint (dBfs) >>> [key=agc_setpoint, default=-30, type=int, range=[-60, 0]] >>> * BiasT Enable - BiasT Control >>> [key=biasT_ctrl, default=true, type=bool] >>> * RfNotch Enable - RF Notch Filter Control >>> [key=rfnotch_ctrl, default=true, type=bool] >>> * DabNotch Enable - DAB Notch Filter Control >>> [key=dabnotch_ctrl, default=true, type=bool] >>> >>> >>> -- RX Channel 0 >>> >>> Full-duplex: NO >>> Supports AGC: YES >>> Stream formats: CS16, CF32 >>> Native format: CS16 [full-scale=32767] >>> Antennas: RX >>> Corrections: DC removal >>> Full gain range: [0, 48] dB >>>IFGR gain range: [20, 59] dB >>>RFGR gain range: [0, 9] dB >>> Full freq range: [0.01, 2000] MHz >>>RF freq range: [0.01, 2000] MHz >>>CORR freq range: MHz >>> Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps >>> Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz >>> >> > >
Re: How to tell whether gnuradio is using NEON or not?
Hi Marcus, Thanks for the clarification. I guess in this case, seeing as volk correctly detected the presence of neon during the compilation process but found the generic machine to be faster, then I can assume, as you said, that GCC 9 is indeed doing a better job than the hand optimized assembly! On Fri, 15 Nov 2019 at 14:57, Müller, Marcus (CEL) wrote: > > Hi Amr, > > that just either means that the kernel has no NEON implementation so > far, so generic is the only choice, or, and that's *good* news, the > compiler has gotten so smart that it outranks hand-written code. > > Best regards, > Marcus > > On Fri, 2019-11-15 at 14:01 +0300, Amr Bekhit wrote: > > Going back to this problem, I recently set up a fresh Raspberry Pi 4 > > system using Ubuntu Server 19.10 and compiled GNU Radio v3.7.13.5 from > > source, which also compiled the built in Volk. I then ran volk_profile > > and was surprised to find that the generic machine was very often > > faster than NEON, and that most of the entries in volk_config > > preferred the generic machine. This seems incorrect - what could the > > mistake be? > > > > == > > Here are the build settings: > > > > ubuntu@ubuntu:~$ uname -a > > Linux ubuntu 5.3.0-1012-raspi2 #14-Ubuntu SMP Mon Nov 11 10:06:55 UTC > > 2019 aarch64 aarch64 aarch64 GNU/Linux > > > > ubuntu@ubuntu:~$ volk-config-info --version > > 2.0 > > > > ubuntu@ubuntu:~$ volk-config-info --cc > > cc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 > > > > ubuntu@ubuntu:~$ volk-config-info --cflags > > /usr/bin/cc:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall > > -Wno-uninitialized -Wall > > generic_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > neon_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > -funsafe-math-optimizations > > neonv8:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > -funsafe-math-optimizations -funsafe-math-optimizations > > > > ubuntu@ubuntu:~$ volk-config-info --avail-machines > > generic_orc;neon_orc;neonv8; > > > > volk-config-info --machine > > neon_orc > > > > == > > Here's the output of volk_profile: > > > > ubuntu@ubuntu:~$ volk_profile > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > generic completed in 1312.04 ms > > neon completed in 1378.97 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > generic completed in 1292.81 ms > > neon completed in 1390.73 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > generic completed in 1311.04 ms > > neon completed in 1397.88 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_16u_byteswappuppet_16u(131071,1987) > > generic completed in 224.223 ms > > neon completed in 278.588 ms > > neon_table completed in 359.529 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_32u_byteswappuppet_32u(131071,1987) > > generic completed in 425.049 ms > > neon completed in 752.16 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_32u_popcntpuppet_32u(131071,1987) > > no architectures to test > > RUN_VOLK_TESTS: volk_64u_byteswappuppet_64u(131071,1987) > > no architectures to test > > RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc(131071,1987) > > generic completed in 2390.53 ms > > neon completed in 927.447 ms > > Best aligned arch: neon > > Best unaligned arch: neon > > RUN_VOLK_TESTS: volk_8u_conv_k7_r2puppet_8u(131071,1987) > > no architectures to test > > RUN_VOLK_TESTS: volk_32f_x2_fm_detectpuppet_32f(131071,1987) > > no architectures to test > > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f(131071,1987) > > no architectures to test > > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i(131071,1987) > > generic completed in 118.046 ms > > neon completed in 108.788 ms > > u_orc completed in 133.196 ms > > Best aligned arch: neon > > Best unaligned arch: neon > > RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2(131071,1987) > > generic completed in 279.341 ms > > u_orc completed in 625.402 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2(131071,1987) > > generic completed in 602.508 ms > > neon completed in 611.587 ms > > u_orc completed in 5000.92 ms > > Best aligned arch: generic > > Best unaligned arch: generic > > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i(131071,1987) > > no architectures to test > > RUN_VOLK_TESTS: volk_16ic_magnitude_16i(131071,1987) > > no architectures to test > > RUN_VO
qt-gui problems with GNU 3.8
I am trying to build gnuradio branch maint-3.8 and I am having trouble getting qt-gui to enabled. I am currently using the new distro CentOS 8, and I cannot find any ‘qwt’ packages. Has anyone got gnuradio to build on CentOS 8 yet? I am very close to having all the modules I desire to be built and enabled. Any help would be greatly appreciated. Mark Here is the cmake error output for qt-gui. -- Python checking for PyQt5 - found -- Checking for module 'Qt5Qwt6' -- Package 'Qt5Qwt6', required by 'virtual:world', not found -- -- Configuring gr-qtgui support... -- Dependency Boost_FOUND = 1 -- Dependency QT_FOUND = 1 -- Dependency QWT_FOUND = FALSE -- Dependency ENABLE_VOLK = TRUE -- 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 Here are my final modules enabled ad disabled. -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support -- * doxygen -- * gnuradio-runtime -- * gr-ctrlport -- * * thrift -- * gnuradio-companion -- * gr-blocks -- * gr-fec -- * gr-fft -- * gr-filter -- * gr-analog -- * gr-digital -- * gr-dtv -- * gr-audio -- * * oss -- * gr-channels -- * gr-trellis -- * gr-uhd -- * gr-utils -- * gr_modtool -- * gr-vocoder -- * gr-wavelet -- -- ## -- # Gnuradio disabled components -- ## -- * sphinx -- * gr-qtgui -- * gr-video-sdl -- * gr-zeromq --
Re: How to tell whether gnuradio is using NEON or not?
... which either means that's fine, or we need more (or sometimes, better) NEON implementations. If this is critical to you, let us get you onboard with VOLK development – and get your NEON code upstreamed! :D Best regards, Marcus On Fri, 2019-11-15 at 21:34 +0300, Amr Bekhit wrote: > Hi Marcus, > > Thanks for the clarification. I guess in this case, seeing as volk > correctly detected the presence of neon during the compilation process > but found the generic machine to be faster, then I can assume, as you > said, that GCC 9 is indeed doing a better job than the hand optimized > assembly! > > On Fri, 15 Nov 2019 at 14:57, Müller, Marcus (CEL) wrote: > > Hi Amr, > > > > that just either means that the kernel has no NEON implementation so > > far, so generic is the only choice, or, and that's *good* news, the > > compiler has gotten so smart that it outranks hand-written code. > > > > Best regards, > > Marcus > > > > On Fri, 2019-11-15 at 14:01 +0300, Amr Bekhit wrote: > > > Going back to this problem, I recently set up a fresh Raspberry Pi 4 > > > system using Ubuntu Server 19.10 and compiled GNU Radio v3.7.13.5 from > > > source, which also compiled the built in Volk. I then ran volk_profile > > > and was surprised to find that the generic machine was very often > > > faster than NEON, and that most of the entries in volk_config > > > preferred the generic machine. This seems incorrect - what could the > > > mistake be? > > > > > > == > > > Here are the build settings: > > > > > > ubuntu@ubuntu:~$ uname -a > > > Linux ubuntu 5.3.0-1012-raspi2 #14-Ubuntu SMP Mon Nov 11 10:06:55 UTC > > > 2019 aarch64 aarch64 aarch64 GNU/Linux > > > > > > ubuntu@ubuntu:~$ volk-config-info --version > > > 2.0 > > > > > > ubuntu@ubuntu:~$ volk-config-info --cc > > > cc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 > > > > > > ubuntu@ubuntu:~$ volk-config-info --cflags > > > /usr/bin/cc:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall > > > -Wno-uninitialized -Wall > > > generic_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > neon_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > -funsafe-math-optimizations > > > neonv8:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > -funsafe-math-optimizations -funsafe-math-optimizations > > > > > > ubuntu@ubuntu:~$ volk-config-info --avail-machines > > > generic_orc;neon_orc;neonv8; > > > > > > volk-config-info --machine > > > neon_orc > > > > > > == > > > Here's the output of volk_profile: > > > > > > ubuntu@ubuntu:~$ volk_profile > > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > > generic completed in 1312.04 ms > > > neon completed in 1378.97 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > > generic completed in 1292.81 ms > > > neon completed in 1390.73 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > > generic completed in 1311.04 ms > > > neon completed in 1397.88 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_16u_byteswappuppet_16u(131071,1987) > > > generic completed in 224.223 ms > > > neon completed in 278.588 ms > > > neon_table completed in 359.529 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_32u_byteswappuppet_32u(131071,1987) > > > generic completed in 425.049 ms > > > neon completed in 752.16 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_32u_popcntpuppet_32u(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_64u_byteswappuppet_64u(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc(131071,1987) > > > generic completed in 2390.53 ms > > > neon completed in 927.447 ms > > > Best aligned arch: neon > > > Best unaligned arch: neon > > > RUN_VOLK_TESTS: volk_8u_conv_k7_r2puppet_8u(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_32f_x2_fm_detectpuppet_32f(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i(131071,1987) > > > generic completed in 118.046 ms > > > neon completed in 108.788 ms > > > u_orc completed in 133.196 ms > > > Best aligned arch: neon > > > Best unaligned arch: neon > > > RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2(131071,1987) > > > generic completed in 279.341 ms
Re: qt-gui problems with GNU 3.8
Oh, CentOS 8 is out! Nice, I was waiting for that. Let me check whether I can reproduce. Best regards, Marcus On Fri, 2019-11-15 at 19:19 +, Mark Koenig wrote: > I am trying to build gnuradio branch maint-3.8 and I am having trouble > getting qt-gui to enabled. I am currently using the new distro CentOS 8, and > I cannot find any ‘qwt’ packages. Has anyone got gnuradio to build on CentOS > 8 yet? I am very close to having all the modules I desire to be built and > enabled. > > Any help would be greatly appreciated. > > Mark > > Here is the cmake error output for qt-gui. > > -- Python checking for PyQt5 - found > -- Checking for module 'Qt5Qwt6' > -- Package 'Qt5Qwt6', required by 'virtual:world', not found > -- > -- Configuring gr-qtgui support... > -- Dependency Boost_FOUND = 1 > -- Dependency QT_FOUND = 1 > -- Dependency QWT_FOUND = FALSE > -- Dependency ENABLE_VOLK = TRUE > -- 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 > > Here are my final modules enabled ad disabled. > > -- # Gnuradio enabled components > -- ## > -- * python-support > -- * testing-support > -- * doxygen > -- * gnuradio-runtime > -- * gr-ctrlport > -- * * thrift > -- * gnuradio-companion > -- * gr-blocks > -- * gr-fec > -- * gr-fft > -- * gr-filter > -- * gr-analog > -- * gr-digital > -- * gr-dtv > -- * gr-audio > -- * * oss > -- * gr-channels > -- * gr-trellis > -- * gr-uhd > -- * gr-utils > -- * gr_modtool > -- * gr-vocoder > -- * gr-wavelet > -- > -- ## > -- # Gnuradio disabled components > -- ## > -- * sphinx > -- * gr-qtgui > -- * gr-video-sdl > -- * gr-zeromq > -- > > > > smime.p7s Description: S/MIME cryptographic signature
Re: qt-gui problems with GNU 3.8
Hi Mark, On 15/11/2019 21.19, Mark Koenig wrote: > I am trying to build gnuradio branch maint-3.8 and I am having trouble > getting qt-gui to enabled. I am currently using the new distro CentOS 8, and > I cannot find any ‘qwt’ packages. Has anyone got gnuradio to build on CentOS > 8 yet? I am very close to having all the modules I desire to be built and > enabled. > > Any help would be greatly appreciated. The qwt package is usually available from the EPEL repositories[1] but there are still no package for epel8, see [2] [1] https://fedoraproject.org/wiki/EPEL [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751172 Regards, Vasil
Re: qt-gui problems with GNU 3.8
Ah, it's the same old blues; need to have qt(4)-devel packaged for qwt. (What I've tried is: Run Fedora as host, and have a podman (or docker, as if I care, replace "podman" by "docker" below) container marcus@workstation> podman run -it --rm centos:8) This is a very rough rundown of what I just did in a fresh CentOS 8 container: [root@hash /]# dnf check-update; dnf install -y epel-release [root@hash /]# dnf update -y [root@hash /]# dnf install -y make rpm-build qt5-qt*-devel rpmdevtools ccache [root@hash /]# adduser mockbuild [root@hash /]# cd [root@hash ~]# curl -o qwt-6.1.3-11.fc31.src.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/31/Everything/source/tree/Packages/q/qwt-6.1.3-11.fc31.src.rpm [root@hash ~]# rpm -i qwt-6.1.3-11.fc31.src.rpm I had to hunt down a lot of qt4 lines in the qwt.spec and remove them before this builds on CentOS 8. I have just attached a diff for a successfully building Qwt6 on the Bug that Vasil mentioned [2], so we can try that one; continue with [root@hash ~]# cd rpmbuild/SPECS [root@hash SPECS]# rm qwt.spec [root@hash SPECS]# curl -o qwt.spec https://bugzilla.redhat.com/attachment.cgi?id=1636615 [root@hash SPECS]# rpmbuild -bs qwt.spec [root@hash SPECS]# cd ../SRPMS [root@hash SRPMS]# rpmbuild -rb *.src.rpm … wit … This should, if the build succeeds (mine is still running), give you qwt6-qt5 packages. Install these! [root@hash SRPMS]# cd ../RPMS/ [root@hash RPMS]# ls */* noarch/qwt-doc-6.1.3-11.el8.noarch.rpm x86_64/qwt-qt5-6.1.3-11.el8.x86_64.rpm x86_64/qwt-qt5-devel-6.1.3-11.el8.x86_64.rpm x86_64/qwt-debugsource-6.1.3-11.el8.x86_64.rpm x86_64/qwt-qt5-debuginfo-6.1.3-11.el8.x86_64.rpm [root@hash RPMS]# cd x86_64 [root@hash x86_64]# dnf install -y * Try to build GNU Radio now! Best regards, Marcus On Fri, 2019-11-15 at 21:46 +0200, Vasil Velichkov wrote: > Hi Mark, > > On 15/11/2019 21.19, Mark Koenig wrote: > > I am trying to build gnuradio branch maint-3.8 and I am having trouble > > getting qt-gui to enabled. I am currently using the new distro CentOS 8, > > and I cannot find any ‘qwt’ packages. Has anyone got gnuradio to build on > > CentOS 8 yet? I am very close to having all the modules I desire to be > > built and enabled. > > > > Any help would be greatly appreciated. > > The qwt package is usually available from the EPEL repositories[1] but there > are still no package for epel8, see [2] > > [1] https://fedoraproject.org/wiki/EPEL > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751172 > > Regards, > Vasil > smime.p7s Description: S/MIME cryptographic signature
Contribute to GNU radio
Hi, I’m an engineering student of third year who have been using this tool for 1 year and i love GNU radio. Now i feel that i can contribute to this project and help the free software, but i don’t know if i got the needed skills. I would like to help developing tools because i know a few programming languages (java, c++ and Python) at a basic / intermediate level, and i know the basics of signal processing which is learnt in college. Do you got any recommendation for me? Are my skills good enough to start contributing to this project? Thanks in advance.
Re: Contribute to GNU radio
César, yes, absolutely. Just get started and see where you have troubles. Make sure you can install GNU Radio (you can start with our Launchpad installation), and then see what you can / can't do. If you're asking for something specific, how about you do the guided tutorials (you can find them on the wiki), and see if they are still up to date? Welcome to this community! Martin On Fri, Nov 15, 2019 at 12:58 PM César fumfum wrote: > Hi, > > > > I’m an engineering student of third year who have been using this tool for > 1 year and i love GNU radio. Now i feel that i can contribute to this > project and help the free software, but i don’t know if i got the needed > skills. > > > > I would like to help developing tools because i know a few programming > languages (java, c++ and Python) at a basic / intermediate level, and i > know the basics of signal processing which is learnt in college. > > > > Do you got any recommendation for me? Are my skills good enough to start > contributing to this project? > > Thanks in advance. >
Re: Contribute to GNU radio
Hi César! It's awesome that you want to help! If you've used GNU Radio before, then: YOU DEFINITELY HAVE THE SKILLS! Generally, we always need people to 1. Write documentation, 2. Test our current development version, 3. Report and reproduce bugs, 4. Review pull requests, 5. Fix bugs and 6. implement new features. So, pick any one of these six problems! We have a tag "good first issue" on the GNU Radio bug tracker[1]. Try these; I hope these are actually good first issues in that they are easy enough for a beginner to both pick up how to work with the project as community as much as as code base whilst still teaching you a bit about everyday problems of GNU Radio. I especially like #1971 [2], where we're still missing a few illustrating flow graphs in gr-qtgui/examples for every single Qt GUI visualization, and a screenshot in the Block Documentation of the Qt Blocks [3]. That would actually combine 1., 2., probably 3. and potentially 5., and maybe even 6. in one task! You might want to install the current "master" branch of GNU Radio. If you're on Ubuntu, that's pretty easy (thanks to Josh's new Ubuntu PPA), if not, you'll need to build from source. Best regards, Marcus [1] https://github.com/gnuradio/gnuradio/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 [2] https://github.com/gnuradio/gnuradio/issues/1971 [3] https://wiki.gnuradio.org/index.php?title=Category:Block_Docs&pagefrom=Q#mw-pages On Fri, 2019-11-15 at 20:56 +, César fumfum wrote: > Hi, > > I’m an engineering student of third year who have been using this tool for 1 > year and i love GNU radio. Now i feel that i can contribute to this project > and help the free software, but i don’t know if i got the needed skills. > > I would like to help developing tools because i know a few programming > languages (java, c++ and Python) at a basic / intermediate level, and i know > the basics of signal processing which is learnt in college. > > Do you got any recommendation for me? Are my skills good enough to start > contributing to this project? > Thanks in advance. smime.p7s Description: S/MIME cryptographic signature
Re: Contribute to GNU radio
Hi Martin, César, > If you're asking for something specific, how about you do the guided > tutorials (you can find them on the wiki), and see if they are still up to > date? Oh, yes! I totally forgot about these. Yes, going through these with an as-modern-as-possible GNU Radio installation would be super helpful. It's really hard for us "old" users to assess whether these tutorials are actually still working well enough for users that haven't developed GNU Radio themselves. Also, I'm pretty sure GRC looks pretty different from when most of the screenshots therein were taken, so if you just follow along these instructions with a GNU Radio 3.8 or newer installation, and re-take the screenshots, that would be immensely helpful. Like, that would definitely make my day. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
