Fwd: Osmocom discourse as alternative to mailing lists

[Philip Balister]

It will be interesting to see how this works out. I encourage anyone 
with an interest in osmocom project to sign up.


Philip


 Forwarded Message 
Subject: Osmocom discourse as alternative to mailing lists
Date: Thu, 27 Jul 2023 13:10:44 +0200
From: Harald Welte 
Reply-To: open...@lists.osmocom.org
To: osmocom-annou...@lists.osmocom.org
CC: baseband-de...@lists.osmocom.org, g...@lists.osmocom.org, 
gr-...@lists.osmocom.org, op25-...@lists.osmocom.org, 
open...@lists.osmocom.org, osmocom-ana...@lists.osmocom.org, 
osmocom-net-g...@lists.osmocom.org, osmocom-...@lists.osmocom.org


Dear Osmocom community,

while many people with a long history in FOSS development have no issues
at all with mailing lists as primary form of engaging with their
community, they have undoubtedly fallen out of fashion in favor of
various chat/messaging systems or web based forums.

In Osmocom, we've just launched an installation of the discourse forum
software available at https://discourse.osmocom.org/ providing an
alternative to our traditional mailing lists at https://lists.osmocom.org/

We're looking forward to see whether this web-based approach will
facilitate more and/or other people to engage with the Osmocom
developer/contributor community.

Feel free to join and get the discussions started.  If there's a need
for more categories or sub-categories, just let one of the moderators
know and we can help with that.

The old mailing lists will continue to remain available for those who
prefer them.

--
- Harald Weltehttps://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 
Ch. A6)

Re: Promblems with gr-air-modes in gnuradio 3.10

[Philip Balister]

On 10/3/22 09:34, Michelle wrote:

Hi Cinaed,

thank you for your answer, It seems like modes_rx (gr3.9 branch) under 
GNU Radio 3.10 hangs somewhere on startup. @willcode4  will try to debug 
it.


https://github.com/bkerler/gnuradio_install/blob/main/install.sh#L275

Suggests this is not fully ported to 3.10 yet.

Philip




have a good day.

On 2022-10-02 19:52, Cinaed Simson wrote:

Hi Michelle - the  source code version of gr-air-modes from github

  https://github.com/bistromath/gr-air-modes.git

indicates it should build under 3.9 but it doesn't build 3.10 - it 
can't find


  GrSwig

which is no longer supported.

Sometimes OOT modules which work on 3.9 work on 3.10 - sometimes they 
don't.


It's possible your version gr-air-modes has a different author from 
git hub version above.


And I don't have a version of 3.9 either so I can't test it on 3.9 .

-- Cinaed



On 10/1/22 05:18, Michelle wrote:

Hello,

I have gnuradio 3.10 and I wanted to install gr-air-modes. In the 
chat one of the moderators told me the version of gr-air-modes that 
is compatible with gr3.9 would work with gr3.10.
So I installed this version in my computer, the installation was 
successfull however when I execute rx_modes I do not receive any 
signal. The output of the command is :


Inspiron-3793:~$ modes_rx
gr-air-modes warning: numpy+scipy not installed, FlightGear interface 
not supported
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; 
UHD_3.15.0.0-2build5
[INFO] [B200] Loading firmware image: 
/usr/share/uhd/images/usrp_b200_fw.hex...

[INFO] [B200] Detected Device: B200
[INFO] [B200] Loading FPGA image: 
/usr/share/uhd/images/usrp_b200_fpga.bin...

[INFO] [B200] Operating over USB 2.
[INFO] [B200] Detecting internal GPSDO
[INFO] [GPS] No GPSDO found
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
[INFO] [B200] Asking for clock rate 32.00 MHz...
[INFO] [B200] Actually got clock rate 32.00 MHz.
Setting gain to 38
Gain is 38
Rate is 400

please can i get some support to solve this problem?

Re: Release Candidates v3.10.2.0-rc1 and v3.9.6.0-rc1

[Philip Balister]

On 4/2/22 08:59, Jeff Long wrote:

Release candidates for our March release are available at:

https://github.com/gnuradio/gnuradio/releases/tag/v3.10.2.0-rc1 

https://github.com/gnuradio/gnuradio/releases/tag/v3.9.6.0-rc1 



OK, they were tagged in March. A few nice fixes/changes popped up at the 
last minute, so we let it slide a little. If everything looks good, the 
final releases will be published in a few days.


I had to add 
0001-Cross-compiling-is-skipping-c-tests-don-t-try-to-set.patch to 
3.9.6.0-rc1 to get configure to run on the sausage machine.


Hopefully results start appearing here later today:

https://github.com/balister/gnnuradio-ptest

3.10 is on honister-qemu-next and 3.9 is on hardknott-qemu-next

Philip

Re: Cross compile gnuradio in E312 error

[Philip Balister]

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: Poor Data Rates with the USRP E312

[Philip Balister]

With the downloaded images for UHD-4.0 I saw a couple of things:

1) The CPU clock speed is set for speed grade 1 parts, not speed grade 3.
2) UHD-4.0 hangs after a while at higher data rates, I've also seen this
on a b200.

If there are fixes for these issues, you might get a bit more transfer
rate. Not sure it will get you the speed you need though.

Philip

On 11/22/20 9:20 PM, Joe Crossen wrote:
>  Hi all,
> 
> I'm attempting to use the USRP E312 as a wifi node using the gr-ieee802.11
> module...
> though for now I'm testing basic USRP functionality with a couple of simple
> GNU graphs.
> 
> Here's my setup:
> - the host is an Ubuntu 18.04 virtual machine with a bridged adaptor.
> Firewall disabled.
> - the USRP is the E312, connected via ethernet to the host network.
> - the host and USRP are both running GR3.8 and UHD4.0 (Zeus branch).
> - the host can see the USRP with uhd_usrp_probe.
> - the USRP is running the following GNU graph - UHD:USRP Source -> UDP Sink.
> - host is running the following GNU graph - UDP Source -> QT GUI Sink.
> - all block parameters are default.
> 
> I'm experiencing the following issues:
> 1. For sample rates > ~2Msps, the USRP spams overrun "O" and "D" characters
> (what does the "D" signify?) , regardless of whether the host graph is
> running or not.
> 2. At any sample rate the host graph spams the following message (when the
> USRP graph is running) - "gr::log :WARN: udp_source0 - Too much data;
> dropping packet."
> 
> And a question:
> 3. What sample rates are realistic for this setup, and what are the
> limitations? wifi channels span 20MHz, so I'm hoping to run at 20Msps
> 
> Thanks,
> Joe
> 

Re: Compiling/installing GNURadio for the STM32MP157C-EV1 board (STM32MP1 processor)

[Philip Balister]

Also note ST supports the Yocto project, you should be able to add

https://github.com/balister/sdr-build/tree/dunfell-qemu

to their BSP and get images with gnuradio. I might even poke at this a
little to get an idea how good their BSP is.

Philip



On 6/4/20 3:40 AM, Henrique Do Carmo Miranda wrote:
> Hi all,
> 
> I would like to install and test GnuRadio on the STM32MP157C-EV1 processor 
> evaluation board for the STM32MP1 processor 
> (https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-eval-boards/stm32mp157c-ev1.html
>  
> ),
>  along with the USRP B205mini.
> 
> Do any of you know if compiling and installing GNURadio on this platform has 
> been attempted before, and if so do you have any pointers that can guide me 
> through that process - could not find any info on it (just wondering if 
> compiled images might be out there)? 
> 
> If not, setting up a Linux machine with all the tools to cross-compile 
> GNUradio for the STM32MP1 target would be the way to go here?
> Would https://wiki.gnuradio.org/index.php/Embedded_Development_with_GNU_Radio 
>  be 
> the best guide to this process?
> 
> 
> Thanks much for your help,
> Henrique
> 
> 

Re: Finding performance issues

[Philip Balister]

perf top can work really well for this.

Although as noted earlier, the Pi series of computers is a serious can
of worms.

Philip

On 5/26/20 3:29 PM, John Langworthy wrote:
> Hello,
> 
> I am working on a fairly simple GMSK receiver that needs to run on a 
> Raspberry 
> Pi 4. Its dropping some large packets and I suspect a performance bottleneck 
> somewhere. It runs perfectly on a desktop.
> 
> I think CtrlPort Monitor will help me find it and I’ve tried to build 
> gnuradio 
> with support for it, unsuccessfully at the moment.
> 
> I am surprised that I am having so much difficulty with CtrlPort Monitor, 
> perhaps its not heavily used and hence maintained. What is the normal 
> workflow 
> for moving from desktop top to embedded, finding performance issues and 
> determining how much CPU/timing headroom is left?
> 
> Thanks
> 
> John
> 

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

What version gnuradio is installed on the E310?

$ gnuradio-config-info -v

There should be a cmake variable to set the python interpreter version.
That might be better than trying to point at libraries in the sdk.

Try -DPYTHON_EXECUTABLE=python (or path to python in the sdk)

Philip

On 2/21/20 11:54 AM, Ivan Iudice wrote:
> How can I force canale to use python 2.7?
> I tried configuring as in:
> https://pastebin.com/EZfNkcGy
> Cmake said that 3.5 is required, but finished configuring; anyway I compiled 
> and installed, but nothing changed.
> 
> Ivan
> 
>> Il giorno 21 feb 2020, alle ore 16:22, Philip Balister  
>> ha scritto:
>>
>> On 2/21/20 3:21 AM, Ivan Iudice wrote:
>>> Hi all,
>>> gnuradio-companion calls the interpreter
>>> #!/usr/bin/env python
>>> Thus, the first python in the path is Python 2.7.
>>> Is gnuradio using python 2.7?
>>
>> Yes, try convincing cmake to use python2 for your OOT.
>>
>> Philip
>>
>>>
>>> Ivan
>>>
>>>>> Il giorno 20 feb 2020, alle ore 20:51, Philip Balister 
>>>>>  ha scritto:
>>>>
>>>> Try:
>>>>
>>>> $ less `which gnuradio-companion`
>>>>
>>>> And see which python interpreter gnuradio-companion uses. Hopefully
>>>> someone from Ettus support knows for sure and can help with the OOT.
>>>>
>>>> Your OOT looks like it is using python3
>>>>
>>>> Philip
>>>>
>>>>> On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
>>>>> Hi Ivan,
>>>>>
>>>>> GNU Radio 3.7: Python2
>>>>> GNU Radio 3.8: Py2 XOR Py3
>>>>> GNU Radio >3.8: Py3
>>>>>> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
>>>>>> Your help is very welcome!
>>>>>> I’m sorry for the stupid question, however, how can I know which version 
>>>>>> of python is used by gnuradio?
>>>>>>
>>>>>> Ivan
>>>>>>
>>>>>>> Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
>>>>>>>  ha scritto:
>>>>>>>
>>>>>>> On 2/20/20 11:25 AM, Ivan Iudice wrote:
>>>>>>>> Hi Philip!
>>>>>>>> I only have site-package folder in both python2.7 and python3.5 lib 
>>>>>>>> folders, no dist-package.
>>>>>>>> The problem is that in python3.5/site-package there is not numpy, it’s 
>>>>>>>> only in python2.7/site-package.
>>>>>>>> Is it not installed for python3? How can I install it in both the sdk 
>>>>>>>> sysroot and in the target?
>>>>>>>
>>>>>>> hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
>>>>>>> versions.
>>>>>>>
>>>>>>> Sorry for the short answer, trying to help, but I don't use the Ettus
>>>>>>> builds for gnuradio.
>>>>>>>
>>>>>>> Philip
>>>>>>>
>>>>>>>> Thanks so much.
>>>>>>>>
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>>>>>>>>>>  ha scritto:
>>>>>>>>>
>>>>>>>>> I had some dist-packages versus site-packages with some versions of
>>>>>>>>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>>>>>>>>>
>>>>>>>>> Philip
>>>>>>>>>
>>>>>>>>>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>>>>>>>>>> I’m curious to know if there is somebody in the list developing for 
>>>>>>>>>> E310 using current SDK.
>>>>>>>>>> This is a problem that, obviously, everybody wants execute custom 
>>>>>>>>>> module could incur.
>>>>>>>>>> Any ideas?
>>>>>>>>>>
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>>>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha 
>>>>>>>>>>>> scritto:
>>>>>>>>>>>
>>>>>>>>>>> 

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

On 2/21/20 3:21 AM, Ivan Iudice wrote:
> Hi all,
> gnuradio-companion calls the interpreter
> #!/usr/bin/env python
> Thus, the first python in the path is Python 2.7.
> Is gnuradio using python 2.7?

Yes, try convincing cmake to use python2 for your OOT.

Philip

> 
> Ivan
> 
>> Il giorno 20 feb 2020, alle ore 20:51, Philip Balister  
>> ha scritto:
>>
>> Try:
>>
>> $ less `which gnuradio-companion`
>>
>> And see which python interpreter gnuradio-companion uses. Hopefully
>> someone from Ettus support knows for sure and can help with the OOT.
>>
>> Your OOT looks like it is using python3
>>
>> Philip
>>
>>> On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
>>> Hi Ivan,
>>>
>>> GNU Radio 3.7: Python2
>>> GNU Radio 3.8: Py2 XOR Py3
>>> GNU Radio >3.8: Py3
>>>> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
>>>> Your help is very welcome!
>>>> I’m sorry for the stupid question, however, how can I know which version 
>>>> of python is used by gnuradio?
>>>>
>>>> Ivan
>>>>
>>>>> Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
>>>>>  ha scritto:
>>>>>
>>>>> On 2/20/20 11:25 AM, Ivan Iudice wrote:
>>>>>> Hi Philip!
>>>>>> I only have site-package folder in both python2.7 and python3.5 lib 
>>>>>> folders, no dist-package.
>>>>>> The problem is that in python3.5/site-package there is not numpy, it’s 
>>>>>> only in python2.7/site-package.
>>>>>> Is it not installed for python3? How can I install it in both the sdk 
>>>>>> sysroot and in the target?
>>>>>
>>>>> hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
>>>>> versions.
>>>>>
>>>>> Sorry for the short answer, trying to help, but I don't use the Ettus
>>>>> builds for gnuradio.
>>>>>
>>>>> Philip
>>>>>
>>>>>> Thanks so much.
>>>>>>
>>>>>> Ivan
>>>>>>
>>>>>>>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>>>>>>>>  ha scritto:
>>>>>>>
>>>>>>> I had some dist-packages versus site-packages with some versions of
>>>>>>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>>>>>>>
>>>>>>> Philip
>>>>>>>
>>>>>>>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>>>>>>>> I’m curious to know if there is somebody in the list developing for 
>>>>>>>> E310 using current SDK.
>>>>>>>> This is a problem that, obviously, everybody wants execute custom 
>>>>>>>> module could incur.
>>>>>>>> Any ideas?
>>>>>>>>
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha scritto:
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> Dear all,
>>>>>>>>> finally I cross-compiled my OOT module for running on USRP E310.
>>>>>>>>> Based on the instructions at 
>>>>>>>>> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source;,
>>>>>>>>>  I set the environment variable PYTHONPATH a little bit different, to 
>>>>>>>>> point the path of the installed OOT module:
>>>>>>>>>
>>>>>>>>> export PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>>>>>>>>>
>>>>>>>>> Such a way, on the target I can load my custom module in python.
>>>>>>>>> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
>>>>>>>>> I created a flowgraph that use my OOT module, and I discovered in the 
>>>>>>>>> newer file system for E310 python3 has not all of the needed 
>>>>>>>>> libraries.
>>>>>>>>> root@ni-e31x-316AFEA:~# ./top_block.py
>>>>>>>>> Traceback (most recent call last):
>>>>>>>>> File "./top_block.py"

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

Try:

$ less `which gnuradio-companion`

And see which python interpreter gnuradio-companion uses. Hopefully
someone from Ettus support knows for sure and can help with the OOT.

Your OOT looks like it is using python3

Philip

On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
> Hi Ivan,
> 
> GNU Radio 3.7: Python2
> GNU Radio 3.8: Py2 XOR Py3
> GNU Radio >3.8: Py3
> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
>> Your help is very welcome!
>> I’m sorry for the stupid question, however, how can I know which version of 
>> python is used by gnuradio?
>>
>> Ivan
>>
>>> Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
>>>  ha scritto:
>>>
>>> On 2/20/20 11:25 AM, Ivan Iudice wrote:
>>>> Hi Philip!
>>>> I only have site-package folder in both python2.7 and python3.5 lib 
>>>> folders, no dist-package.
>>>> The problem is that in python3.5/site-package there is not numpy, it’s 
>>>> only in python2.7/site-package.
>>>> Is it not installed for python3? How can I install it in both the sdk 
>>>> sysroot and in the target?
>>>
>>> hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
>>> versions.
>>>
>>> Sorry for the short answer, trying to help, but I don't use the Ettus
>>> builds for gnuradio.
>>>
>>> Philip
>>>
>>>> Thanks so much.
>>>>
>>>> Ivan
>>>>
>>>>>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>>>>>>  ha scritto:
>>>>>
>>>>> I had some dist-packages versus site-packages with some versions of
>>>>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>>>>>
>>>>> Philip
>>>>>
>>>>>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>>>>>> I’m curious to know if there is somebody in the list developing for E310 
>>>>>> using current SDK.
>>>>>> This is a problem that, obviously, everybody wants execute custom module 
>>>>>> could incur.
>>>>>> Any ideas?
>>>>>>
>>>>>> Ivan
>>>>>>
>>>>>>>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha scritto:
>>>>>>>
>>>>>>> 
>>>>>>> Dear all,
>>>>>>> finally I cross-compiled my OOT module for running on USRP E310.
>>>>>>> Based on the instructions at 
>>>>>>> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source;,
>>>>>>>  I set the environment variable PYTHONPATH a little bit different, to 
>>>>>>> point the path of the installed OOT module:
>>>>>>>
>>>>>>> export PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>>>>>>>
>>>>>>> Such a way, on the target I can load my custom module in python.
>>>>>>> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
>>>>>>> I created a flowgraph that use my OOT module, and I discovered in the 
>>>>>>> newer file system for E310 python3 has not all of the needed libraries.
>>>>>>> root@ni-e31x-316AFEA:~# ./top_block.py
>>>>>>> Traceback (most recent call last):
>>>>>>> File "./top_block.py", line 12, in 
>>>>>>>   from gnuradio import blocks
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
>>>>>>>  line 38, in 
>>>>>>>   from .stream_to_vector_decimator import *
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
>>>>>>>  line 23, in 
>>>>>>>   from gnuradio import gr
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
>>>>>>>  line 46, in 
>>>>>>>   from .top_block import *
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py",
>>>>>>>  line 32, in 
>>>>>>>   from .hier_block2 import hier_block2
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py",
>>>>>>>  line 26, in 
>>>>>>>   import pmt
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py",
>>>>>>>  line 61, in 
>>>>>>>   from .pmt_to_python import pmt_to_python as to_python
>>>>>>> File 
>>>>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/pmt_to_python.py",
>>>>>>>  line 23, in 
>>>>>>>   import numpy
>>>>>>> ImportError: No module named 'numpy'
>>>>>>> How could I solve the problem?
>>>>>>> I'm so close to run my OOT modules on the target...
>>>>>>> Thanks so much.
>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 Giga 
>>>>>>> in 4G a soli 8,99€ al mese. http://tisca.li/smart30
>>>>>>>
>>
>>

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

On 2/20/20 11:25 AM, Ivan Iudice wrote:
> Hi Philip!
> I only have site-package folder in both python2.7 and python3.5 lib folders, 
> no dist-package.
> The problem is that in python3.5/site-package there is not numpy, it’s only 
> in python2.7/site-package.
> Is it not installed for python3? How can I install it in both the sdk sysroot 
> and in the target?

hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
versions.

Sorry for the short answer, trying to help, but I don't use the Ettus
builds for gnuradio.

Philip

> Thanks so much.
> 
> Ivan
> 
>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister  
>> ha scritto:
>>
>> I had some dist-packages versus site-packages with some versions of
>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>>
>> Philip
>>
>>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>>> I’m curious to know if there is somebody in the list developing for E310 
>>> using current SDK.
>>> This is a problem that, obviously, everybody wants execute custom module 
>>> could incur.
>>> Any ideas?
>>>
>>> Ivan
>>>
>>>>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha scritto:
>>>>
>>>> 
>>>> Dear all,
>>>> finally I cross-compiled my OOT module for running on USRP E310.
>>>> Based on the instructions at 
>>>> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source;,
>>>>  I set the environment variable PYTHONPATH a little bit different, to 
>>>> point the path of the installed OOT module:
>>>>
>>>> export PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>>>>
>>>> Such a way, on the target I can load my custom module in python.
>>>> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
>>>> I created a flowgraph that use my OOT module, and I discovered in the 
>>>> newer file system for E310 python3 has not all of the needed libraries.
>>>> root@ni-e31x-316AFEA:~# ./top_block.py
>>>> Traceback (most recent call last):
>>>>  File "./top_block.py", line 12, in 
>>>>from gnuradio import blocks
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
>>>>  line 38, in 
>>>>from .stream_to_vector_decimator import *
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
>>>>  line 23, in 
>>>>from gnuradio import gr
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
>>>>  line 46, in 
>>>>from .top_block import *
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py",
>>>>  line 32, in 
>>>>from .hier_block2 import hier_block2
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py",
>>>>  line 26, in 
>>>>import pmt
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py", 
>>>> line 61, in 
>>>>from .pmt_to_python import pmt_to_python as to_python
>>>>  File 
>>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/pmt_to_python.py",
>>>>  line 23, in 
>>>>import numpy
>>>> ImportError: No module named 'numpy'
>>>> How could I solve the problem?
>>>> I'm so close to run my OOT modules on the target...
>>>> Thanks so much.
>>>> Ivan
>>>>
>>>>
>>>>
>>>> Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 Giga in 
>>>> 4G a soli 8,99€ al mese. http://tisca.li/smart30
>>>>
>>>
> 
> 

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

I had some dist-packages versus site-packages with some versions of
gnuradio. See if both exist. I'm betting numpy is in site-packages.

Philip

On 2/19/20 4:46 PM, Ivan Iudice wrote:
> I’m curious to know if there is somebody in the list developing for E310 
> using current SDK.
> This is a problem that, obviously, everybody wants execute custom module 
> could incur.
> Any ideas?
> 
> Ivan
> 
>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha scritto:
>>
>> 
>> Dear all,
>> finally I cross-compiled my OOT module for running on USRP E310.
>> Based on the instructions at 
>> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source;,
>>  I set the environment variable PYTHONPATH a little bit different, to point 
>> the path of the installed OOT module:
>>
>> export PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>>
>> Such a way, on the target I can load my custom module in python.
>> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
>> I created a flowgraph that use my OOT module, and I discovered in the newer 
>> file system for E310 python3 has not all of the needed libraries.
>> root@ni-e31x-316AFEA:~# ./top_block.py
>> Traceback (most recent call last):
>>   File "./top_block.py", line 12, in 
>> from gnuradio import blocks
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
>>  line 38, in 
>> from .stream_to_vector_decimator import *
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
>>  line 23, in 
>> from gnuradio import gr
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
>>  line 46, in 
>> from .top_block import *
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py",
>>  line 32, in 
>> from .hier_block2 import hier_block2
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py",
>>  line 26, in 
>> import pmt
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py", 
>> line 61, in 
>> from .pmt_to_python import pmt_to_python as to_python
>>   File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/pmt_to_python.py",
>>  line 23, in 
>> import numpy
>> ImportError: No module named 'numpy'
>> How could I solve the problem?
>> I'm so close to run my OOT modules on the target...
>> Thanks so much.
>> Ivan
>>
>>
>>
>> Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 Giga in 
>> 4G a soli 8,99€ al mese. http://tisca.li/smart30
>>
> 

Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8

[Philip Balister]

On 1/8/20 3:07 AM, Sylvain Munaut wrote:
>> We use pkgconfig(gr-iqbal) style BuildRequires in our rpm spec files for
>> installation during package builds where we can and are somewhat
>> confused as to why you did this.
> 
> Because GR 3.8 doesn't use .pc files to determine which path to
> include and which libs are needed to build and I don't like have two
> independent "source of truth". New modules created by gr-modtool also
> don't include pc files.
> 
> It uses some new CMake magic which I'm not entirely sure how it works
> really but it seems it does. My understanding is it's automatically
> generated from the scoping of the target_link_libraries /
> target_include_directories (i.e. PUBLIC ones will be passed on to
> children) using the whole autogenerated FindGnuradioIqbalance.cmake
> thing that cmakes creates and installs automatically.
> 
> That should be enough for building or do you get link / include issues ?
> 
>> I have only looked at gr-iqbal so far, so if any of the others have had
>> the same treatment then ... :)
>>
>> Oh yes and I could not find any path to a release tarball for
>> gr-iqbal-0.38.1.
>> If there is a spec. friendly one I would love to know where it is.
>> I can normally find them in github or SF but cgit is another story.
> 
> There isn't, we disabled it in cgit.  Lots of crawlers wouldn't obey
> the robots.txt and kept crawling the link and since that archive is
> dynamically generated, it would overload the server with crawlers
> trying to download every archive of every branch and every tag for
> every projects ...
> 
> You either need to make and host your own, or download from the github
> mirror ( https://github.com/osmocom/gr-iqbal/releases )

Standard warning, github is known to regenerate tarballs with different
contents that lead to sha has mismatches with time making it hard to
validate the downloaded tarball. Don't depend on githb downloaded
tarballs if you care about supply chain integrity.

Philip

> 
> Cheers,
> 
> Sylvain
> 

Re: [Discuss-gnuradio] buffer allocation failing with RuntimeError: bad_alloc

[Philip Balister]

Look in

${HOME}/.gnuradio/prefs/vmcircbuf_default_factory

and see what is there and maybe change to this:

gr::vmcircbuf_mmap_tmpfile_factory

Philip


On 11/21/19 4:59 AM, Eamon Heaney wrote:
> I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11,
> substituting a null sink for the USRP sink to test it.
> 
> When I try to run it, it fails with the following error message:
> "
>> set_min_output_buffer on block 7 to 207744
>> set_min_output_buffer on block 9 to 2077440
>> set_min_output_buffer on block 11 to 2077440
>> set_min_output_buffer on block 12 to 207744
>> set_min_output_buffer on block 13 to 415488
>> set_min_output_buffer on block 14 to 207744
>> set_min_output_buffer on block 26 to 262144
>> set_min_output_buffer on block 27 to 96000
>> set_min_output_buffer on block 31 to 10
>> gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory
>> gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB
>> gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory
>> gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB
>> Traceback (most recent call last):
>>  File "/home/vtti/working/wifi_tx.py", line 297, in 
>>main()
>>  File "/home/vtti/working/wifi_tx.py", line 276, in main
>>tb.start()
>>  File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/top_block.py",
> line 111, >in start
>>top_block_start_unlocked(self._impl, max_noutput_items)
>>  File
> "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/runtime_swig.py", line
>> 5828, in top_block_start_unlocked
>>return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
>> RuntimeError: std::bad_alloc
> "
> Here's a picture of my flowchart:
> [image: gnuradio-runtimeError-bad_alloc.png]
> 
> Tested this on a different machine, and it works fine, so the problem isn't
> with the flowchart itself. I'm working off the maint-3.8 branch, installed
> from source.
> 
> Any idea why I'm getting this error, or how I could resolve it? Thanks!
> 

Re: How to tell whether gnuradio is using NEON or not?

[Philip Balister]

Raspbian is built for the original pi, that cpu does not have a neon
coprocessor. Basically, use a different distro that supports modern pi
hardware.

Philip

On 11/3/19 8:10 AM, Amr Bekhit wrote:
> Hello all,
> 
> I'm working on a project that involves selecting and filtering 10-15
> narrow channels (10kHz bandwidth) from a relatively broadband input
> (1Mhz). I've been working on trying to implement this as performant as
> possible using GNURadio companion (see this email thread
> https://lists.gnu.org/archive/html/discuss-gnuradio/2019-10/msg00192.html).
> I tried of couple of things (using FIR bandpass filters, mixing each
> channel down to 0Hz then low pass filtering (both in one step and in
> stages), using FIR bandpass filters) and found that simply using FIR
> bandpass filters for each channel seemed to provide the best
> performance CPU-wise (20% CPU usage on my i7-920 desktop PC). However,
> the aim is to run this system on a Raspberry Pi 4 and unfortunately,
> the same flow runs at approximately 90% CPU and seems to cause lags
> when sending the data to the SDR (LimeSDR-USB).
> 
> I see the problem as potentially one of the following:
> - The flow is *still* not as efficient as it could be.
> - The RPi4 is just not powerful enough to run something like this and
> I need to use something more powerful (perhaps like the x86 Lattepanda
> boards?)
> - GNURadio is not compiled to use NEON optimisations.
> 
> I've been exploring the last point recently and wanted to check
> whether NEON optimisations are indeed being utilised. So here's what I
> did:
> - I set up a Raspberry Pi 4 (4GB) using Raspbian Buster.
> - I installed GNURadio from the standard apt repository. This installs
> GNU Radio v3.7.13.4 and Volk 1.4
> - I ran volk_profile to tune the library.
> - I then run the bpf-test flow (attached to this email). The CPU usage is 70%.
> 
> Some info about the gnuradio and volk versions:
> gnuradio-config-info --cflags:
> /usr/bin/cc::: -g -O2
> -fdebug-prefix-map=/build/gnuradio-FK7QfY/gnuradio-3.7.13.4=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -std=gnu99 -fvisibility=hidden -Wsign-compare
> -Wall -Wno-uninitialized
> /usr/bin/c++::: -g -O2
> -fdebug-prefix-map=/build/gnuradio-FK7QfY/gnuradio-3.7.13.4=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> 
> volk-config-info --cflags:
> /usr/bin/cc::: -g -O2 -fdebug-prefix-map=/build/volk-zBrTqH/volk-1.4=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall
> /usr/bin/c++::: -g -O2
> -fdebug-prefix-map=/build/volk-zBrTqH/volk-1.4=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall
> generic_orc:::GNU::: -g -O2
> -fdebug-prefix-map=/build/volk-zBrTqH/volk-1.4=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall
> 
> volk-config-info --avail-machines
> generic_orc;
> 
> So based on that, it appears that the gnuradio and volk packages on
> Raspbian are not built with NEON support. I then set about compiling
> gnuradio and volk from source to ensure that NEON support is included.
> I compiled *both* volk and gnuradio using the
> arm_cortex_a72_hardfp_native.cmake toolchain file that is included in
> the cmake/Toolchains folder in the volk source. I compiled volk
> separately and then when compiling gnuradio set
> ENABLE_INTERNAL_VOLK=OFF. In this case, I ended up compiling Volk v2.0
> and gnuradio v3.9.0.0 (master from git). Here are the compiler flags:
> 
> gnuradio-config-info --cflags
> /usr/bin/gcc:::-O3 -DNDEBUG -march=armv8-a -mtune=cortex-a72
> -mfpu=neon-fp-armv8 -mfloat-abi=hard -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized
> /usr/bin/g++:::-O3 -DNDEBUG -march=armv8-a -mtune=cortex-a72
> -mfpu=neon-fp-armv8 -mfloat-abi=hard -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized
> 
> volk-config-info --cflags
> /usr/bin/gcc::: -march=armv8-a -mtune=cortex-a72 -mfpu=neon-fp-armv8
> -mfloat-abi=hard -Wall
> /usr/bin/g++::: -march=armv8-a -mtune=cortex-a72 -mfpu=neon-fp-armv8
> -mfloat-abi=hard -Wall
> generic_orc:::GNU:::-O3 -DNDEBUG -march=armv8-a -mtune=cortex-a72
> -mfpu=neon-fp-armv8 -mfloat-abi=hard -Wall
> neon_orc:::GNU:::-O3 -DNDEBUG -march=armv8-a -mtune=cortex-a72
> -mfpu=neon-fp-armv8 -mfloat-abi=hard -Wall -funsafe-math-optimizations
> neonv7_hardfp_orc:::GNU:::-O3 -DNDEBUG -march=armv8-a
> -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -Wall
> -funsafe-math-optimizations -mfpu=neon -funsafe-math-optimizations
> -mfloat-abi=hard
> 
> volk-config-info --avail-machines
> generic_orc;neon_orc;neonv7_hardfp_orc;
> 
> volk-config-info --machine
> neonv7_hardfp_orc
> 
> After running volk_profile to tune the library, I then ran the same
> flow, hoping that I'd get improved performance. Unfortunately, the
> 

[Discuss-gnuradio] Osmocom team looking for new gr-osmosdr maintainer

[Philip Balister]

gr-osmosdr is still a useful block today. Please read this email and
think about becoming the maintainer.

http://lists.osmocom.org/pipermail/osmocom-sdr/2019-September/001983.html

Thanks,

Philip

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

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[Philip Balister]

On 07/30/2019 07:48 PM, Glen Langston wrote:
> Hi Marcus and all
> 
> Thanks for all your efforts.
> 
> I've built gnuradio 3.7.13.4 successfully on a Raspberry Pi 4
> and am saving an image of a 32GB SD card.   This image happens to
> run perfectly fine on a Pi 3B+ as well.  And a copy on another PI 4 I just
> purchased.
> 
> I'm using AIRSPY and PlutoSDR dongles, but have not tried more advanced
> devices.
> 
> However I also tried building 3.8 and had all kinds of troubles.   CMAKE
> did not
> work easily.  Eventually found an apt-get remove cmake followed
> by an apt-get install cmake fixed that, but building cmake did not work.
> 
> Then I had trouble building Volk and several other components on the PI 4.

What distro are you running on the pi4? What are the specific errors?

Philip

> 
> So, the upgrade path to 3.8 is not easy from the build-it-yourself point of
> view.
> 
> Will it be possible to get
> 
> apt-get install gnuradio3.8
> 
> to work? with the new volk?
> 
> On Raspberry pi 4, mostly I end up using generic versions of Volk in
> earlier version.
> 
> Thanks again for your efforts!
> 
> Glen
> 
> I'll post the location of the R PI 4, once I've confirmed that others can
> use it.
> 
> 
> On Tue, Jul 30, 2019 at 5:29 PM Marcus Müller  wrote:
> 
>> Hello VOLKy people,
>>
>> on coming Monday, we'll release the next VOLK version. This is utterly
>> necessary so that we have a definitive version to use for the GNU Radio
>> 3.8.0.0 release.
>>
>> That VOLK release will be VOLK 2.0.0, marking the start of VOLK using
>> Semantic Versioning [1].
>>
>> If you want code to be part of that release, please finish it by
>> Thursday, the first of August. Don't fret, we'll be regularly doing
>> VOLK releases in the future.
>>
>> Best regards,
>> Marcus
>>
>> [1] https://semver.org
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Python3 or still Python 2.7?

[Philip Balister]

On 06/17/2019 10:49 AM, Chesir, Aaron M. wrote:
> Will GNUradio migrate to Python3.X, or will it remain with Python 2.7?
> 
> The reason I ask is that (for reasons that unclear), there are syntax 
> differences between the two, and Python 3 is *not* backward compatible for 
> some of them.

The GNURadio master branch (which will become 3.8) supports Python3.

Philip

> 
> Aaron
> 
> -Original Message-
> From: Discuss-gnuradio  
> On Behalf Of Geof Nieboer
> Sent: Saturday, June 15, 2019 5:25 PM
> To: Discuss-gnuradio@gnu.org
> Subject: [EXT] [Discuss-gnuradio] Windows Installers v1.6 for v3.7.13.5 
> published
> 
> All,
> 
> Updated windows installers that include 3.7.13.5 have now been published.
> 
> They can be found as always at http://www.gcndevelopment.com/gnuradio.
> 
> Key windows specific fixes in the installers include:
> 1- Windows Audio Sink now doesn't distort for certain audio streams
> 2- ZeroMQ is working again
> 3- GR_PREFIX is now defined in the run_gr.bat so that sys-wide configuration 
> files will be used correctly.
> 
> Numerous dependencies have been updated:
> GNURadio -> 3.7.13.5
> Qt > 5.12.3
> numpy -> 1.64.4
> libxml2 -> 2.9.9
> libpng -> 1.6.37
> UHD -> 3.14.1*
> zmq -> 4.3.1
> libusb -> 1.0.22
> openssl -> 1.0.1r
> qwt6 -> 6.1.4
> log4cpp -> 1.1.3
> pycairo -> 1.17.1
> sip -> 4.18
> 
> * RC1... a new version will be pushed if RC1 requires changes prior to formal 
> release
> 
> While no new OOT modules have been added, here's the list of what is included:
> 
> gr-acars2
> gr-adsb
> gr-ais
> gr-air-modes
> gr-ax25
> gr-burst (incl. bitarray)
> gr-cdma
> gr-display (incl. matplotlib)
> gr-eventstream
> gr-fosphor
> gr-gsm
> gr-inspector (incl. tensorflow)
> gr-iqbal
> gr-lte
> gr-mapper
> gr-nacl
> gr-osmosdr
> gr-paint (incl. PIL)
> gr-radar
> gr-rds
> gqrx
> 
> and driver support for: UHD / RTL2382 / HackRF / BladeRF / AirSpy / Funcube 
> Dongle
> 
> Known Issues:
> 
> - (new) Windows Audio Source only supports single channel input.
> Use portaudio for stereo source use cases.
> - gr-air-modes gui does not work, but the command line interface will
> - Switching between debug and release versions will cause
> intermittent heap corruption issues.  Re-run application.
> - TCP Sink/Server are deprecated and do not function in the
> windows version, use zeromq blocks
> - File Sink/Server blocks do not function in the windows version.
> - gr-newmod still does not work without a great deal of workarounds
> - agc3 block will run, but will respond more slowly than on
> linux... still under investigation.
> 
> A complete stack of symbols is available for the release and debug builds, to 
> allow tracing all the way down to python itself.
> 
> For those intrepid enough to want to build all of this yourself, the scripts 
> are now compatible with building 3.8 or 3.7 by changing the version in 
> ConfigInfo.psd1 to 3.8.0, then it should build the correct dependencies to 
> support it.  Drivers are built but OOT blocks are not yet built for 3.8.  
> While most of the work in this release was to enable a functioning build for 
> 3.8, I am not planning to release an installer for 3.8 at this point, but 
> email me if you have a need for a pre-alpha build.
> 
> When a 3.8 build is released, they will be installable simultaneously without 
> issue.
> 
> And finally, to make things a bit easier for the intrepid, I have published 
> an AWS AMI image set to a validated build configuration to make it a bit 
> easier for others to run the build scripts.  Details on the github site:
> http://github.com/gnieboer/GNURadio_Windows_Build_Scripts
> 
> Cheers,
> 
> Geof
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Can't open GNURadio Companion as root?

[Philip Balister]

On 06/08/2019 02:00 PM, Eamon Heaney wrote:
> Hey all, I'm getting a gtk error when I try to run gnuradio-companion as
> root. Error message below.
> 
> File "/usr/bin/gnuradio-companion", line 97, in 
> check_gtk()
>   File "/usr/bin/gnuradio-companion", line 64, in check_gtk
> die(err, "Failed to initialize GTK. If you are running over ssh, "
>   File "/usr/bin/gnuradio-companion", line 42, in die
> import gtk
>   File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line
> 69, in 
> _init()
>   File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line
> 57, in _init
> warnings.warn(str(e), _gtk.Warning)
> gtk.GtkWarning: could not open display
> 
> 
> The instructions on the github repo I'm working from indicate that I should
> be running this as root, so I do think it's necessary. Any ideas on how to
> fix this?

That sounds like a terrible idea (running gnuradio-companion as root).
Where is this github repo?

That said, I've seen it run as root on embedded boards so there nothing
in the code to stop it.

The could not open display message suggest you are trying to run over
ssh without using X forwarding.

Philip


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

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

Re: [Discuss-gnuradio] [EXT] Re: complaints about missing volk.h

[Philip Balister]

On 05/29/2019 09:11 AM, Chesir, Aaron M. wrote:
> Marcus,
> 
> As you can see from the attached, I ran cmake, and then make, and was greeted 
> at the end with the same (what appear to be) C++ errors.
> 
> What *exactly* can I do to get a good "make", followed by a good "make 
> install" ?

Don't run make until you are happy with the output of cmake .

Scanning that I see these lines I would fix:

-- Python checking for PyYAML >= 3.10 - not found
-- Python checking for mako >= 0.9.1 - not found

-- Python checking for PyQt5 - not found
-- Checking for module 'Qt5Qwt6'
--   No package 'Qt5Qwt6' found
-- QWT Version: 6.1.1
-- Could NOT find Qwt (missing: QWT_LIBRARIES)

I'd also pay close attention to Marcus comment on uhd versions. You may
have more than one installed.

Philip

> 
> Aaron
> 
> -Original Message-
> From: Müller, Marcus (CEL)  
> Sent: Tuesday, May 28, 2019 4:59 PM
> To: Chesir, Aaron M. ; discuss-gnuradio@gnu.org
> Subject: Re: [EXT] Re: [Discuss-gnuradio] complaints about missing volk.h
> 
> Please stay on the mailing list.
> 
> Running make without successfully running CMake is meaningless.
> Also errors pertaining to third party libraries are in 99% of cases
> simply caused by the user having competing versions of the same library
> installed, and that will likely be the case here for UHD.
> 
> Next step: purge all conflicting installation of things that you both
> built from source and directly or indirectly installed via packages.
> The quickest way to do that is running on a clean slate system.
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-05-28 at 19:04 +, Chesir, Aaron M. wrote:
>> Marcus,
>>
>> Thank you for your willingness to help.
>>
>> I followed your instructions, and was able to run cmake, but when I
>> ran "make", although it did progress to 99% completion, it complained
>> about syntax errors in the code - most of which involve UHD (see
>> attached).
>>
>> What should be my next step?
>>
>> Thanks,
>>
>> Aaron
>>
>>
>> -Original Message-
>> From: Müller, Marcus (CEL)  
>> Sent: Tuesday, May 28, 2019 1:41 PM
>> To: Chesir, Aaron M. ; discuss-gnuradio@gnu.org
>> Subject: [EXT] Re: [Discuss-gnuradio] complaints about missing volk.h
>>
>> Seems you didn't quite install things into a place CMake looks into
>> by
>> default; quite possibly, there will be needs to tell CMake about
>> /usr/local/include/volk (which is what I guess is the default
>> installation prefix if you build from source manually).
>>
>> Anyway, this wouldn't have helped you! Please don't install a random
>> VOLK, that doesn't work; instead, uninstall what you've installed
>> now,
>> and 
>>
>> git clone --recursive https://github.com/gnuradio/gnuradio
>> /home/xroot/GNUradio2/
>> cd /home/xroot/GNUradio2/
>> mkdir build
>> cd build
>> cmake ..
>>
>> Due to the recursive clone, you get an in-tree copy of VOLK that
>> matches exactly your GNU Radio version. 
>> CMake will recognize the presence of that, and then build VOLK
>> alongside with GNU Radio.
>>
>> Again, I've said this multiple times: going for the source build on
>> CentOS 7 is not what I'd like to recommend. That's why I have the
>> repo with an RPM package that I referred you to before.
>>
>> Best regards,
>> Marcus
>>
>> On Tue, 2019-05-28 at 17:27 +, Chesir, Aaron M. wrote:
>>> Folks,
>>>  
>>> I am trying to install GNUradio from source:
>>> I downloaded a copy of the gnuradio master repository into my local
>>> folder /home/xroot/GNUradio2/,
>>> I created a subdirectory called "build",
>>> within that sub-directory, I can execute "cmake ../".
>>>  
>>> When I execute "make", I keep getting the (attached) error about
>>> missing "volk.h"
>>>  
>>> I then installed VOLK from source (cmake, make, sudo make install),
>>> and then went back to my attempt at building GNUradio:
>>> I went back to the "build" directory,
>>> I ran "make clean",
>>> I ran "cmake ../"
>>> I ran "make"
>>>  
>>> …and I keep getting the very same error message.
>>>  
>>> Help.
>>>  
>>> Thanks,
>>>  
>>> Aaron
>>>  
>>>  
>>> When I execute
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] VOLK, gnuradio does not compile

[Philip Balister]

Or use

 -DENABLE_INTERNAL_VOLK=OFF

when you run cmake.

Volk living in and out of the source tree is painful. Time to toss it
out and let it stand alone! Makes it easier for third party programs to
actually use it.

Philip

On 05/22/2019 07:37 AM, Ralph A. Schmid, dk5ras wrote:
> Hi Hans, 
> 
>  
> 
> Did you follow the recommendation from the error message, to check out and
> enable volk? Then again cmake, make...
> 
>  
> 
> With best regards
> 
> 
> Ralph.
> 
>  
> 
>  
> 
>  
> 
> --
> 
>  
> 
> Ralph A. Schmid
> 
> Mondstr. 10
> 
> 90762 Fürth
> 
> +49-171-3631223
> 
> +49-911-21650056
> 
> ra...@schmid.xxx
> 
> http://www.bclog.de/
> 
>  
> 
>  
> 
>  
> 
> From: Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Hans
> Kurscheidt
> Sent: Wednesday, May 22, 2019 1:31 PM
> To: Discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] VOLK, gnuradio does not compile
> 
>  
> 
> Hi,
> 
> I'm not so sure, if i'm duplicating another issue, but gnuradio does not
> compile from source. I have 
> 
> libvolk1-bin, libvolk1-dev and libvolk1.3 installed. I also executed  install mako>; -- no cure 
> 
> Here the log: 
> 
> hk@orangepizero:~/Downloads/gnuradio/build$ cmake ../
> -- The CXX compiler identification is GNU 6.3.0
> -- The C compiler identification is GNU 6.3.0
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Found Git: /usr/bin/git
> -- Extracting version information from git describe...
> -- Performing Test HAVE_VISIBILITY_HIDDEN
> -- Performing Test HAVE_VISIBILITY_HIDDEN - Success
> -- Performing Test HAVE_WARN_SIGN_COMPARE
> -- Performing Test HAVE_WARN_SIGN_COMPARE - Success
> -- Performing Test HAVE_WARN_ALL
> -- Performing Test HAVE_WARN_ALL - Success
> -- Performing Test HAVE_WARN_NO_UNINITIALIZED
> -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
> -- Compiler Version: cc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> Copyright (C) 2016 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
> -- Building Static Libraries: OFF
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_create
> -- Looking for pthread_create - not found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Boost version: 1.62.0
> -- Found the following Boost libraries:
> --   date_time
> --   program_options
> --   filesystem
> --   system
> --   thread
> --   chrono
> --   atomic
> -- Found PythonLibs: /usr/lib/arm-linux-gnueabihf/libpython2.7.so (found
> suitable version "2.7.13", minimum required is "2")
> --
> -- Checking for module SWIG
> -- Found SWIG version 3.0.10.
> -- Found SWIG: /usr/bin/swig3.0
> --
> -- The build system will automatically enable all components.
> -- Use -DENABLE_DEFAULT=OFF to disable components by default.
> --
> -- Configuring python-support support...
> --   Dependency PYTHONLIBS_FOUND = TRUE
> --   Dependency SWIG_FOUND = TRUE
> --   Dependency SWIG_VERSION_CHECK = TRUE
> --   Enabling python-support support.
> --   Override with -DENABLE_PYTHON=ON/OFF
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
> -- Checking for module 'cppunit'
> --   Found cppunit, version 1.13.2
> -- Found CPPUNIT: /usr/lib/arm-linux-gnueabihf/libcppunit.so;dl
> --
> -- Configuring testing-support support...
> --   Dependency CPPUNIT_FOUND = TRUE
> --   Enabling testing-support support.
> --   Override with -DENABLE_TESTING=ON/OFF
> --
> -- Configuring VOLK support...
> --   VOLK submodule is not checked out.
> --   To check out the VOLK submodule, use:
> -- git pull --recurse-submodules=on
> -- git submodule update
> --   External VOLK disabled.
> --   Override with -DENABLE_INTERNAL_VOLK=ON/OFF
> --
> CMake Error at CMakeLists.txt:313 (message):
>   VOLK required but not found.
> 
> 
> -- Configuring incomplete, errors occurred!
> See also "/home/hk/Downloads/gnuradio/build/CMakeFiles/CMakeOutput.log".
> See also 

[Discuss-gnuradio] Fwd: Fwd: UC Berkeley seeks postdoctoral researchers

[Philip Balister]

Open source related position at berkeley.

Philip


 Forwarded Message 
Subject: Fwd: UC Berkeley seeks postdoctoral researchers
Date: Fri, 17 May 2019 10:45:18 -0400
From: Mike Balister 
To: Philip Balister 



> Begin forwarded message:
> 
> From: Jeff Mangum 
> Subject: UC Berkeley seeks postdoctoral researchers
> Date: May 17, 2019 at 9:20:50 AM EDT
> To: ursi-usn...@googlegroups.com
> 
> USNC-URSI Commission J,
> 
> See below for two postdoctoral opportunities offered by Dan Werthimer at UC 
> Berkeley.
> 
> -- Jeff
> 
> 
> we are hoping you can help us post a couple of job openings at berkeley's 
> radio astronomy lab,  
> for researchers to develop infrastructure and digital instrumentation for the 
> radio astronomy community.  
> 
> for more information and application/enquiry, please see
> 
> https://aprecruit.berkeley.edu/JPF02137 
> <https://aprecruit.berkeley.edu/JPF02137>(phd not required) 
> https://aprecruit.berkeley.edu/JPF02148 
> <https://aprecruit.berkeley.edu/JPF02148>(phd or equivalent required) 
> 
> 
> thanks for your help. 
> 
>  best wishes,
> 
> dan (and dave, jack and aaron) 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "URSI-USNC-J" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to ursi-usnc-j+unsubscr...@googlegroups.com 
> <mailto:ursi-usnc-j+unsubscr...@googlegroups.com>.
> To post to this group, send email to ursi-usn...@googlegroups.com 
> <mailto:ursi-usn...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ursi-usnc-j/d8ebfce9-4fc3-2f38-415e-c0177ce68048%40nrao.edu
>  
> <https://groups.google.com/d/msgid/ursi-usnc-j/d8ebfce9-4fc3-2f38-415e-c0177ce68048%40nrao.edu?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.



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

Re: [Discuss-gnuradio] RPi Filesystem Image

[Philip Balister]

On 05/08/2019 12:09 PM, Ben Hilburn wrote:
> Hi Glen -
> 
> We’ve put our event detection on three Raspberry Pi 3B +
>> for confirming events in the forward direction (not side lobes).
>>
> 
> Wow, this is really cool. Thanks so much for sharing!
> 
> 
>> I have a 8 GB image .iso that I could put on line this weekend.
>> Where is appropriate for such large files?  We installed everything
>> on one Pi then just copied the image to the other SD cards.
>>
> 
> That would be excellent! Storage & bandwidth are indeed tough, though.

8 GB sounds a bit large, they should compress fairly well, especially if
new.

Ones I did a while back are like 2 GB:

https://www.dropbox.com/sh/fokcr688h2gshxi/AACcv8PUrTaKZoxPlluFxxZPa?dl=0

Philip

> 
> We (GNU Radio) pay for storage on Google's cloud servers, and we could host
> it there. Do you have a Google account? If so, and you can upload the image
> to a Google Drive account and share it with me, I should be able to easily
> replicate it over to GNU Radio's storage.
> 
> Cheers,
> Ben
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[Philip Balister]

Which Pi?

Philip

On 04/24/2019 03:22 PM, P C wrote:
> Nick, Marcus,
> 
> To answer your osmosdr question I used the instructions here:
> https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR
> 
> And I also did:
> 
> sudo apt-get install rtl-sdr gr-osmosdr
> 
> Since then I did some more experimenting and I believe it is a problem
> with osmosdr.
> I don't know a lot about Raspbian (the RPi OS) or Python but it may be
> that I have multiple versions of Python and that is confusing osmosdr.
> 
> Here is what I did, I found in /usr/local/bin, a program, osmosdr_fft
> which I believe was installed when I installed gr-osmosdr.
> It gives me exactly the same error and Traceback?? that gnuradio gave me.
> I know I have Python 3.??? and Python 2.??? but I don't know enough
> about where Raspbian squirrels away executables to know how to find all
> the Pythons that are installed.?? I used the GUI (startx) search
> function that came with the Pi and found 25 folders named Python and 4
> files named Python.?? I sure don't know what to do with that.
> 
> This is why I believe osmosdr is confused.?? I looked at the Traceback
> and to my (very limited) understanding it looks like osmosdr is trying
> to determine which version of Python is being used.?? The result is it
> thinks it needs to run "_osmosdr_swig"
> but a search for "_osmosdr_swig" in all folders reports that it can't
> find "_osmosdr_swig".
> 
> I am trying to understand the Traceback and the thread through the modules.
> At the risk of driving everybody away I have included, below, both the
> Traceback and then code snippets from the trace points.
> Together it is 2,622 characters and 69 lines if anybody is interested.??
> Don't feel bad if it is TMI.?? I understand.
> 
> Pete
> 
> 
> Here is what is reported:
> Traceback (most recent call last):
> ?? File "/home/pi/Documents/Security/top_block.py", line 28, in 
> ?? import osmosdr
> ?? File "/usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py",
> line 26, in 
> ?? from osmosdr_swig import *
> ?? File
> "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line
> 21, in 
> ?? _osmosdr_swig = swig_import_helper()
> ?? File
> "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line
> 20, in swig_import_helper
> ?? return importlib.import_module('_osmosdr_swig')
> ?? File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
> import_module
> ?? __import__(name)
> ImportError: No module named _osmosdr_swig
> 
> Python code snippets from around the traces are:
> 
> From top_block.py
> 25 from gnuradio.eng_option import eng_option
> 26 from gnuradio.filter import firdes
> 27 from optparse import OptionParser
> 28 import osmosdr
> 29 import sip
> 
> From /usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py
> 25 # import swig generated symbols into the osmosdr namespace
> 26 from osmosdr_swig import *
> 27
> 28 # import any pure python here
> 29 #
> 
>> From /usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py
> 11 from sys import version_info as _swig_python_version_info
> 12 if _swig_python_version_info >= (2, 7, 0):
> 13 def swig_import_helper():
> 14 import importlib
> 15 pkg = __name__.rpartition('.')[0]
> 16 mname = '.'.join((pkg, '_osmosdr_swig')).lstrip('.')
> 17 try:
> 18 return importlib.import_module(mname)
> 19 except ImportError:
> 20 return importlib.import_module('_osmosdr_swig')
> 21 _osmosdr_swig = swig_import_helper()
> 22 del swig_import_helper
> 23 elif _swig_python_version_info >= (2, 6, 0):
> 
> From /usr/lib/python2.7/importlib/__init__.py
> 20 def import_module(name, package=None):
> 21 """Import a module.
> 22
> 23 The 'package' argument is required when performing a relative
> import. It
> 24 specifies the package to use as the anchor point from which
> to resolve the
> 25 relative import to an absolute import.
> 26
> 27 """
> 28 if name.startswith('.'):
> 29 if not package:
> 30 raise TypeError("relative imports require the
> 'package' argument")
> 31 level = 0
> 32 for character in name:
> 33 if character != '.':
> 34 break
> 35 level += 1
> 36 name = _resolve_name(name[level:], package, level)
> 37 __import__(name)
> 38 return sys.modules[name]
> 
> 
> 
> 
> On 4/24/2019 11:31 AM, Nick Hansen wrote:
>> Pete:
>>
>> Sounds like your gnuradio install works fine, but getting the blocks
> for RTL SDR is an issue.
>> Did you try building gr-osmosdr from source?
>> https://osmocom.org/projects/gr-osmosdr/wiki
>> Another possibility is that gnuradio just can't find the osmo blocks.
> In that case you would need to move the blocks from where 

Re: [Discuss-gnuradio] libvolk development

[Philip Balister]

On 12/21/2018 03:01 AM, Albin Stigö wrote:
> Hi GNURadio/libvolk friends,
> 
> I've started filling in the gaps in the in the libvold SIMD matrix
> http://libvolk.org/platforms.html, for NEON.
> 
> Just don't want to step on someone's toes, is anyone else working on
> this, NEON specifically.

If possible can you use intrinsics so the same code can run on armv7 and
armv8?

Philip

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

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

Re: [Discuss-gnuradio] 3.7 to 3.8 transition

[Philip Balister]

On 12/19/2018 10:45 AM, Manolis Surligas wrote:
> Hi everyone,
> 
> is there any walk-through for a proper transition of an OOT module from
> 3.7 to 3.8?
> 
> If an OOT module was created with 3.7 gr_modtool can we still use the
> 3.8 gr_modtool?

These might be good topics for the pre FOSDEM hackfest :)

https://hsbxl.be/events/byteweek/2019/gnuradio/

and

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

Philip

> 
> Regards,
> 
> Manolis
> 

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

Re: [Discuss-gnuradio] Embedded Development with GNU Radio

[Philip Balister]

On 12/10/2018 03:32 PM, Philip Balister wrote:
> On 12/10/2018 03:16 PM, Mohamed Youseif wrote:
>> Hello,
>> I'm trying to build an embedd linux image using yocto project with gnuradio 
>> for my target which is wandboard, so i downloaded the meta-sdr layer ( sumo 
>> branch ), then i configure my local configuration to install all needed 
>> packages (like gnuradio, uhd, gr-burst, etc.) , then i bitbake 
>> core-image-minimal and everythings gone well and get my image and copied it 
>> to my sdcard, i see that i have gnuradio and uhd installed but i did not 
>> found gr-uhd installed in gnuradio core, so when i try to run any uhd 
>> example script it ouput import error for no uhd module. so do i need to do 
>> more configuration to have the gr-uhd installed with my image ?

And the other pain point, I am testing gnuradio/next in master and am
still fixing stuff there. And this is going slowly due to paying work,
holiday season and snow.

Philip

> 
> I disabled uhd since the recipe is bitrotting in meta-sdr and isn't
> buildable. Wait ...
> 
> Hmm, I did get a patch updating it to a buildable version, but it
> doesn't include the fpga image packages update. I applied the patch
> since it improves the situation, but haven't checked against gnuradio.
> 
> You could try setting the PACKAGECONFIG for gnuradio in local.conf and
> add uhd back and see if that works. Or do what I do and use an rtlsdr
> dongle :)
> 
> I apologize for this sorry state of affairs wrt to uhd support.
> 
> Philip
> 
> 
>> Thanks,
>> Yusuf
>> 
>> From: Discuss-gnuradio 
>>  on behalf of 
>> discuss-gnuradio-requ...@gnu.org 
>> Sent: Monday, December 10, 2018 7:00 PM
>> To: discuss-gnuradio@gnu.org
>> Subject: Discuss-gnuradio Digest, Vol 194, Issue 8
>>
>> Send Discuss-gnuradio mailing list submissions to
>> discuss-gnuradio@gnu.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> or, via email, send a message with subject or body 'help' to
>> discuss-gnuradio-requ...@gnu.org
>>
>> You can reach the person managing the list at
>> discuss-gnuradio-ow...@gnu.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Discuss-gnuradio digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: help: optimizing a fm broadcast flowchart. Getting
>>   multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>>   (Cinaed Simson)
>>2. Re: help: optimizing a fm broadcast flowchart. Getting
>>   multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>>   (Cinaed Simson)
>>
>>
>> --
>>
>> Message: 1
>> Date: Sun, 9 Dec 2018 13:39:00 -0800
>> From: Cinaed Simson 
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>> flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>> (Michael Dickens)
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Here's an example of broadcast FM. It's from the first couple of
>> tutorials at
>>
>>   https://greatscottgadgets.com/sdr
>>
>> All you need to do is to change the samp rate and the center_freq, and
>> swap out the osmocom Source for the RTL-SDR Source.
>>
>> Since each channel is roughly 200 kHz wide, you probably won't get more
>> then 2 stations at a sampling rate of 2 MHz.
>>
>> I have HackRF One and it runs fine on my i7 at sampling rate of 20 MHz.
>>
>> However, this was the first time I tried on the i7 - and  when I drop
>> the sampling rate to 2 MHz, I got the 'Ua's  - audio underflows,
>>
>> But it sounded fine. Not sure what is causing the audio underflow.
>>
>> I would guess you should be able to replace the "Signal
>> Source/Multiply/Low Pass Filter" with the "Frequency Xlating FIR Filter"
>> or the "Low Pass Filter/Rational Resampler" with the polyphase filter bank.
>>
>> -- Cinaed
>>
>>
>> On 12/07/2018 11:33 AM, Luis Roca wrote:
>>> Thanks!
>>>
>>> On Fri, Dec 7, 2018 at 1:12 PM >> <mailto:discuss-gnuradio-requ...@gnu.org>> wrote:
>>>
>>> Send Discuss-gnuradio mailing list submissions to
>>> ? ? ? ? discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>

Re: [Discuss-gnuradio] Embedded Development with GNU Radio

[Philip Balister]

On 12/10/2018 03:16 PM, Mohamed Youseif wrote:
> Hello,
> I'm trying to build an embedd linux image using yocto project with gnuradio 
> for my target which is wandboard, so i downloaded the meta-sdr layer ( sumo 
> branch ), then i configure my local configuration to install all needed 
> packages (like gnuradio, uhd, gr-burst, etc.) , then i bitbake 
> core-image-minimal and everythings gone well and get my image and copied it 
> to my sdcard, i see that i have gnuradio and uhd installed but i did not 
> found gr-uhd installed in gnuradio core, so when i try to run any uhd example 
> script it ouput import error for no uhd module. so do i need to do more 
> configuration to have the gr-uhd installed with my image ?

I disabled uhd since the recipe is bitrotting in meta-sdr and isn't
buildable. Wait ...

Hmm, I did get a patch updating it to a buildable version, but it
doesn't include the fpga image packages update. I applied the patch
since it improves the situation, but haven't checked against gnuradio.

You could try setting the PACKAGECONFIG for gnuradio in local.conf and
add uhd back and see if that works. Or do what I do and use an rtlsdr
dongle :)

I apologize for this sorry state of affairs wrt to uhd support.

Philip


> Thanks,
> Yusuf
> 
> From: Discuss-gnuradio 
>  on behalf of 
> discuss-gnuradio-requ...@gnu.org 
> Sent: Monday, December 10, 2018 7:00 PM
> To: discuss-gnuradio@gnu.org
> Subject: Discuss-gnuradio Digest, Vol 194, Issue 8
> 
> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-requ...@gnu.org
> 
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
> 
> 
> Today's Topics:
> 
>1. Re: help: optimizing a fm broadcast flowchart. Getting
>   multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>   (Cinaed Simson)
>2. Re: help: optimizing a fm broadcast flowchart. Getting
>   multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>   (Cinaed Simson)
> 
> 
> --
> 
> Message: 1
> Date: Sun, 9 Dec 2018 13:39:00 -0800
> From: Cinaed Simson 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
> flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
> (Michael Dickens)
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
> 
> Here's an example of broadcast FM. It's from the first couple of
> tutorials at
> 
>   https://greatscottgadgets.com/sdr
> 
> All you need to do is to change the samp rate and the center_freq, and
> swap out the osmocom Source for the RTL-SDR Source.
> 
> Since each channel is roughly 200 kHz wide, you probably won't get more
> then 2 stations at a sampling rate of 2 MHz.
> 
> I have HackRF One and it runs fine on my i7 at sampling rate of 20 MHz.
> 
> However, this was the first time I tried on the i7 - and  when I drop
> the sampling rate to 2 MHz, I got the 'Ua's  - audio underflows,
> 
> But it sounded fine. Not sure what is causing the audio underflow.
> 
> I would guess you should be able to replace the "Signal
> Source/Multiply/Low Pass Filter" with the "Frequency Xlating FIR Filter"
> or the "Low Pass Filter/Rational Resampler" with the polyphase filter bank.
> 
> -- Cinaed
> 
> 
> On 12/07/2018 11:33 AM, Luis Roca wrote:
>> Thanks!
>>
>> On Fri, Dec 7, 2018 at 1:12 PM > > wrote:
>>
>> Send Discuss-gnuradio mailing list submissions to
>> ? ? ? ? discuss-gnuradio@gnu.org 
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> ? ? ? ? https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> or, via email, send a message with subject or body 'help' to
>> ? ? ? ? discuss-gnuradio-requ...@gnu.org
>> 
>>
>> You can reach the person managing the list at
>> ? ? ? ? discuss-gnuradio-ow...@gnu.org
>> 
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Discuss-gnuradio digest..."
>>
>>
>> Today's Topics:
>>
>> ? ?1. Re: help: optimizing a fm broadcast flowchart. Getting
>> ? ? ? multiple stations in a rtlsdr (Derek Kozel) (Luis Roca)
>> ? ?2. Re: help: optimizing a fm broadcast flowchart. Getting
>> ? ? ? multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>> ? ?3. Re: [USRP-users] Segmentation fault commands to USRP with
>> ? ? ? gnuradio (M?ller)
>> ? 

Re: [Discuss-gnuradio] build-gnuradio.sh and Linux Mint 19

[Philip Balister]

Try it and if it works send in a pull request :)

On 10/29/2018 10:11 AM, John Ackermann N8UR wrote:
> Thanks, Neel!  However, I just downloaded the version on github and it
> fails with the same error; the page indicates that the last mods were 11
> months ago, which predates Mint 19.
> 
> John
> 
> 
> On 10/29/18 10:07 AM, Neel Pandeya wrote:
>> The "build-gnuradio" script is now being maintained on GitHub.
>>
>> https://github.com/ccera-astro/build-gnuradio
>>
>> --Neel Pandeya
>>
>>
>>
>>
>> On 29 October 2018 at 07:04, John Ackermann N8UR > > wrote:
>>
>>     I'm trying to run the current build-gnuradio.sh script from
>>     sbrac.org  on a Linux Mint 19 machine and the
>>     script immediately fails, saying "Your Mint release must be at least
>>     Linux Mint 11 to proceed"
>>
>>     Is it safe to just bypass that check, or is there some sort of
>>     incompatibilty with v19?  Or is sbrac.org  no
>>     longer the place to find the current version of the script?
>>
>>     Thanks,
>>     John
>>
>>     ___
>>     Discuss-gnuradio mailing list
>>     Discuss-gnuradio@gnu.org 
>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>     
>>
>>
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] Will gnu radio embedded run on a zynq (pynq) development board?

[Philip Balister]

On 10/07/2018 12:03 AM, Tom Cipollone wrote:
> Hi, my first foray into gnu radio. I am interested in the embedded form of
> gnu radio. I have been doing extensive reading in the documentation and
> found that WRT xilinx zynq development boards there is a guide
> https://wiki.gnuradio.org/index.php/Zynq but there are warnings about the
> instructions being OBSOLETE.
> 
> The warning says "Development moves rapidly in Open Embedded and GNU Radio
> which unfortunately means this guide has become out of date and the
> instructions will likely fail. For now, please refer to our Embedded
>  and OpenEmbedded
>  pages for the latest GNU
> Radio on Zynq information".
> 
> I have gone to the OpenEmbedded pages but have found no further
> instructions as to how to port gnu radio to a zynq board.
> 
> Is anyone currently working with a zynq board and can they provide some
> direction?

I do a lo of work with board support packages for custom Zynq hardware
these days. So I haven't had much time for the public docs :(

The best public example for zynq is:

https://github.com/balister/sdr-build/tree/rocko-e300

I took a quick look for a conf file for the pynq board and didn't see one.

Philip

> 
> Thank You
> Tom
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] LDPC in GNURadio

[Philip Balister]

On 09/19/2018 05:03 PM, Andrej Rode wrote:
> Hi Sylvain, 
> 
> thanks for you thorough look into the state of the LDPC encoder/decoder.
> I just skip the long text of wall and answer your questions from my
> point of view:
> 
>> So my questions would be :
>>
>> (1) Is cleaning up the mess worth it ?
> 
> I personally would like to see the FEC module cleaned up a bit. There is also 
> a
> viterbi decoder in gr-trellis which would be perfectly fine in gr-fec
> and using the gr-fec API. Maybe even porting in the specialized LDPC for
> gr-dtv would be possible for the parameters used in gr-dtv. (which does
> not mean you have to do so)
> 
>> (2) Is completely breaking the API of those blocks acceptable ?
> 
> For post-3.8 releases breaking the API for these blocks (and integrating
> them into the FEC API if they're not already there would be a big plus)
> 
>> (3) Is adding a dependency to M4RI library to gnuradio acceptable ?
>> (possibly optional one, disabling LDPC if not present).
> 
> Looking at M4RI is available in Ubuntu, Fedora and is probably easy to
> add to other Linux distributions/Windows etc etc. 
> It is "only" a math library and has no dependencies beside libc. 

I didn't find an OpenEmbedded recipe for M4RI, but a quick look at the
source suggest it will be easy enough to create a recipe. Give me some
warning if you go this path and I'll work on the recipe.

Philip

> 
> Cheers
> Andrej
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] [UHD] Coarse roadmap for USRP E310 Software

[Philip Balister]

On 07/17/2018 01:50 PM, Moritz Fischer via USRP-users wrote:
> Philip,
> 
> On Fri, Jul 13, 2018 at 8:03 AM, Philip Balister  wrote:
>> A couple of notes based on updating the E300 to rocko 
>>
>> 1) The N310 branch added a bbappend on something called salt which added
>> the need for the meta-openstack and meta-virtualization layers. For
>> basic E300 support, this is crazy layer bloat. I removed the bbappend.
>> If you really need it, I'd create a layer for specific applications,
>> salt seems to be some form of enterprise software config management
>> system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not
>> every E300 project needs this.
> 
> That's a good point, I'll look into making it more modular.
> 
>>
>> 2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to
>> meta-ettus, but it also supports users using other Ettus products with
>> other embedded hardware, so the recipe doesn't belong there. It would be
>> silly having to add the meta-ettus bsp to use a b200 with a pi-s.
> 
> I have made an attempt at splitting up meta-ettus more into separate layers,
> the result of that is on github (master). I was hesitant to push it public 
> since
> in it current form E31x does not work. N310 will move over to that (and the 
> sumo
> release with the next release).
> 
> Personally having the uhd recipe in meta-sdr was not convenient and we ended 
> up
> building most of the filesystems with bbappends to the UHD recipe
> anyways, so I've
> decided to host the UHD recipe in meta-ettus in a meta-ettus-core sublayer.

Well, moving it out of meta-sdr means I'll need to drop the uhd
packagegroups and have the default images not include any usrp hardware,
including things like the b200. Since uhd doesn't build in master, I'll
go ahead and drop uhd and associated bitsfrom meta-sdr there.

I suspect this might make things easier for engineering development, but
long term, I think it will be harder for end users to use usrps with
random dev boards. Time will tell.

Philip


> 
> With upcoming products I hope the modularization makes sense and helps keeping
> changes separate while not reinventing the wheel every time.
> 
>> 3) While messing with uhd, it is time to have the firmware recipe
>> package the fpga files on a per device basis, instead of all images on
>> one package.
> 
> We are/were already working on that. Thanks for your input.
> 
> Cheers,
> Moritz
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

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

Re: [Discuss-gnuradio] [USRP-users] [UHD] Coarse roadmap for USRP E310 Software

[Philip Balister]

A couple of notes based on updating the E300 to rocko 

1) The N310 branch added a bbappend on something called salt which added
the need for the meta-openstack and meta-virtualization layers. For
basic E300 support, this is crazy layer bloat. I removed the bbappend.
If you really need it, I'd create a layer for specific applications,
salt seems to be some form of enterprise software config management
system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not
every E300 project needs this.

2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to
meta-ettus, but it also supports users using other Ettus products with
other embedded hardware, so the recipe doesn't belong there. It would be
silly having to add the meta-ettus bsp to use a b200 with a pi-s.

3) While messing with uhd, it is time to have the firmware recipe
package the fpga files on a per device basis, instead of all images on
one package.

4) There are some other smaller fixes in
https://github.com/balister/meta-ettus-1

Philip

On 07/10/2018 01:54 PM, Martin Braun via USRP-users wrote:
> 
> Hi all E310/E312/E313 users,
> 
> I would like to focus people's attention to some changes we have just
> started rolling out, and will continue to roll out over the next months.
> 
> Executive Summary
> =
> - For those requiring *no* RFNoC support whatsoever, just plain RX/TX
> and UHD support, we recommend sticking with the 3.9 LTS version of UHD
> for now (this advice is for the E310/E312/E313 only!).
> - Going forward, we will be moving the E310 to a more modern RFNoC
> architecture, and start incorporating things we've learned from other
> embedded USRPs.
> - However, this means that certain features (most importantly, network
> mode) will be unavailable for the time being on newer UHD versions until
> the transition is complete.
> 
> 
> Full Story
> ==
> As we've rolled out the USRP N310 and other devices using embedded
> Linux, we have gotten a little smarter with respect to OpenEmbedded and
> other embedded-Linux related topics. For example, the USRP N310 features
> the MPM architecture, which moves a lot of the hardware controls onto
> the device itself, as opposed to toggling every bit in every register
> from within UHD, and we have a better way of creating file systems which
> makes it easier for us to upgrade to newer OE and kernel versions.
> 
> The USRP E310, even though it was released years ago, is still a great
> product, with an amazing form factor. Unfortunately, its software design
> hasn't kept up with the times, and the currently shipping filesystems
> have fairly old kernels, among other things. Over the course of the next
> few months, we intend to remedy that. We will be taking the following steps:
> 
> 1. Port all RFNoC code from E310 onto master branch. This means we no
> longer support different architectures between the master and
> rfnoc-devel branches (note: On X310, we did this for the 3.10 release).
> The main downside of this is that it will disable network mode (i.e.,
> the ability to run the E310 like an N210, with UHD running on a host
> computer, over Ethernet).
> 
> 2. Forward-port the E310 code to the same OE release as we use for N310.
> Since this entails a major kernel upgrade, it will take some time to
> have all the power management up to date. There may be periods of time
> where the E312 (the battery-powered version) will have reduced
> capabilities. We will send out more updates when we know more.
> 
> 3. Forward-port the E310 code the same UHD software architecture as the
> N310. Once this is complete, network mode will be back in place, albeit
> with more capabilities. For RFNoC development in particular, this will
> be useful, because full RFNoC support will be made available over
> network mode (the bandwidth limitations for E310 network will remain the
> same, we expect a nominal sampling rate of 1 Msps over network mode).
> 
> Timeline
> 
> We plan to complete these steps by the end of 2018. The first step,
> however, has already been completed on master branch: Here, the E310 has
> already been synchronized with the code from rfnoc-devel.
> 
> Once this transition is complete, we will be able to keep providing
> updates for the E310 more easily than before, and they will stay in
> lockstep with the N310 filesystem releases.
> 
> Note that since we're merging all of this into master branch, there will
> be intermediate releases of UHD with different feature sets for the E310.
> 
> 
> Which branch/release should I run?
> ==
> If you are using none of the RFNoC features, i.e., you are simply doing
> send() and recv() calls, then we recommend sticking with the UHD-3.9.LTS
> branch.
> If you are doing RFNoC development, then simply move from rfnoc-devel to
> master branch, and everything else stays the same.
> 
> 
> Why do all of this on master branch?
> 
> We could have 

Re: [Discuss-gnuradio] [USRP-users] [UHD] Announcing 3.12.0.0 Release

[Philip Balister]

On 06/06/2018 11:26 AM, Martin Braun via USRP-users wrote:
> Hi all,
> 
> after release-candidating, we have now finalized the 3.12.0.0 release.
> As mentioned before, you might not want to upgrade, but simply run the
> 3.11.1.0 release which has fewer feature-related changes, but most of
> the bugfixes. Here's the decision guidelines which were already in the
> RC1 notes:
> 
> 
> - 3.12.0.0 added White Rabbit support for the N310, so if you need that,
>   you need the newest release.
> - 3.12.0.0 removed some public API calls, it is thus an API-breaking
>   release (note that these were some obscure API calls, most users
>   won't see a difference. GNU Radio users certainly won't).
>   If you want to keep everything as stable as possible, but want all the
>   recent bugfixes, pick the 3.11.1.0 release.
> - If you're still unsure, go through the changelog (pasted below) and
>   see if some of the new features are relevant to your project.
>   Most notably, the addition of the BasicRX A/B muxing for X310 (which
>   was not available since UHD 3.10) and the re-added ability to modulate
>   the DAC on the N210/N200 could be relevant.
> 
> 
> Tag, FPGA images and github-auto-produced tarballs can be found here:
> https://github.com/EttusResearch/uhd/releases/tag/v3.12.0.0

If you are using tarball checksums to validate the tarball, github will
occasionally regenerate the tarball leading to a changed checksum. So if
you are validating tarballs before use, don't depend on stable checksums
from github automatically generated tarballs. Sadly, this makes github
auto created tarballs pretty useless.

Philip

> 
> Windows installers will be found here (they're still being finalized,
> for the next half-day or so this link will still be dead):
> http://files.ettus.com/binaries/uhd/uhd_003.012.000.000-release/
> 
> Cheers all,
> 
> Martin
> 
> 
> 
> 
> 
> 
> 
> Changelog:
> 
> 
> * N3x0: Add White Rabbit support, add N300 support, standard BIST
> 
> includes fan, fix issue with 1GigE, switch to 2 radio blocks
> 
> with 2 channels each, upgrade TDC to version 2.0, fix issue in
> 
> ARM deframer
> 
> * X300: Enable BasicRX to use A/B/AB/BA muxing setups, more consistent
> 
> logging, fix enumeration issue with TwinRX
> 
> * USRP2/N2x0: Re-add ability to modulate in the DAC, improve ISE
> 
>   settings to better meet timing
> 
> * B205mini: Fix global reset, improve timing in b205_ref_pll
> 
> * UHD: Remove a lot of Boost usage, mostly replaced by C++11 features,
> 
>more unit tests, fix Boost 1.67 compatibility, fix compiler
> 
>warnings, add API to query clock rate range, fix get_usrp_?x_info
> 
> * MPM: Refactored N3xx code, moved C++ standard to 14, refactor
> 
>Boost.Python bindings, use CMake variable MPM_DEVICE
> 
> * Logging: Allow disabling fastpath msgs at runtime
> 
> * Docs: Clarified meaning of DSP frequencies, improved manual
> 
> section on synchronization, added some known issues to B100,
> 
> USRP2, and USRP1, update test test procedure description
> 
> * Examples: Improved benchmark_rate (added failure thresholds, fixed
> 
>   incorrect calculation of samples on drops, fixed timeout values),
> 
>   minor fixes to txrx_loopback_to_file
> 
> * Utils: Handle U's in calibration tools, create-lvbitx.py is now Py3k
> 
>  compatible, fixed git-hash.sh
> 
> * RFNoC: DDCs/DUCs use DDSes instead of CORDIC, add DMA-based replay
> 
>  block in FPGA, add 64-bit support to axi_wrapper, add compat
> 
>  number to radio block,
> 
> * Debian: Fix rules file, fix Changelog format
> 
> * Fix license headers
> 
> * This release includes all bugfixes and features from previous
> 
>   releases, in particular, the 3.11.* release cycle
> 
> * Known issues: N310: In some rare scenarios at high rates, streaming
> 
>   can fail and even bring the FPGA into a bad state.
> 
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

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

Re: [Discuss-gnuradio] install issue with c++11

[Philip Balister]

On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
> On 06/05/2018 09:07 AM, Jason Matusiak wrote:
>> Thanks Dave, but that did not seem to work for me.  Here were the
>> commands I ran (slightly different than recommended, but that was for
>> some different recipe mods that have nothing to do with this issue):
>>
>> $ export CXXFLAGS="-std=c++11"
>> $ PREFIX=/opt/gnuradio/v3.7.12.0
>> $ yes | pybombs prefix init $PREFIX
>> $ yes | pybombs -p $PREFIX recipes add gr-recipes
>> git+https://github.com/gnuradio/gr-recipes.git
>> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
>> $ pybombs -vvv -p $PREFIX install gnuradio
>>
>> And currently things keep erroring out at the same place while
>> installing UHD:
>>
>> [ 43%] Building CXX object
>> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
>>
>> [ 43%] Building CXX object
>> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
>>
>> c++: internal compiler error: Killed (program cc1plus)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[2]: ***
>> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
>> Error 4
>> make[2]: *** Waiting for unfinished jobs
>>
>> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
>>
> That error is internal to the compiler, it is failing to perform its job
> correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
>   or any of that.  This ordinarily means you compiler is broken in some
> way.
> 
> HOWEVER.  How much memory do you have on the system?


Run dmesg and look for messages from the OOM killer (Out of Memory)

Philip

> 
> This issue used to happen on systems with small physical memory, because
> compiling certain things requires a lot of virtual memory
>   on the part of the compiler.
> 
> 
>>
>>     Jason,
>>  You can set the CXXFLAGS env variable to "-std=c++11" and any
>>     CMake builds you run (assuming the same shell) will check the
>>     CXXFLAGS var first.  This assumes that you don't overwrite the
>>     value of CMAKE_CXX_FLAGS.  I just tried it in a terminal with
>>     `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
>>     `VERBOSE=1 make -j 1`.  The verbose make command will show you if
>>     your flags are taking or not.
>>     -Dave
>>
>>     On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
>>     >     > wrote:
>>
>>     I am trying to install gnuradio onto a Centos 7 box and am
>>     having more and more issues with packages that use c++11
>>     commands.  For some of the packages, I add the line:
>>     CMAKE_CXX_FLAGS "-std=c++11"
>>     to the module's CMakeLists.txt file.
>>     The issue is that that requires a fetch, the mod, and then a
>>     rebuild.  This worked OK with it was just gqrx I was doing it
>>     for, but now I need it for other modules it appears, and so I
>>     am trying to find a more elegant solution that covers
>>     everything that is built via a pybombs install gnuradio
>>     command (like gr-blocks, which I can't use this trick for).
>>     If I understand the problem correctly, Ubuntu uses new enough
>>     tools to realize that it needs to use the c++11 version (or
>>     newer I assume) to build since it is needed.  It seems like
>>     even though Centos 7 has the c++11 capability, it does not
>>     smartly trying to use it, and must be directed to for the
>>     installs to work.
>>     Is there something I can do at an upper level to make things
>>     happy on an install?
>>     ___
>>     Discuss-gnuradio mailing list
>>     Discuss-gnuradio@gnu.org 
>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] [VOLK] Impact of multitasking on volk_profile

[Philip Balister]

On 05/15/2018 07:50 AM, Álvaro Cebrián Juan wrote:
> Hi everyone,
> 
> If I run the volk_profile utility and in the meantime I do something else
> like internet browsing for example, will it affect/impact the results of
> volk_profile?

It is very possible. Run it on a quiet machine.

Philip

> 
> Thank you.
> Regards,
> 
> Álvaro
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Raspberry Pi 3 / Error: selected processor does not support ARM mode

[Philip Balister]

On 05/08/2018 04:13 PM, Brad Hein wrote:
> Hi Philip,
> 
> How do I go a out trying an alternative as you suggest?

I have a note to do a blog post on building an aarch64 image with
OpenEmbedded, but paying work is interfering. It is fairly straight
forward the meta-raspberrypi  bsp is very good.

Philip

> 
> Thanks!
> 
> [Sent from mobile device]
> 
> On Tue, May 8, 2018, 6:07 PM Philip Balister <phi...@balister.org> wrote:
> 
>> I'm not that familiar wit Raspian, but my impression is that it is
>> binary compatible with the original Pi, which has no neon support. The
>> volk code didn't handle this gracefully until recently.
>>
>> That said, The Pi 3 does support neon and better. For the Pi-3, I'd use
>> something built to take advantage of the better processor.
>>
>> Philip
>>
>>
>> On 05/08/2018 11:08 AM, Brad Hein wrote:
>>> On a new Raspberry Pi 3, running Raspbian, all apt-get package updates
>>> loaded, I'm encountering an error compiling gnuradio (branch: master). I
>>> made one modification from the default source code, and that is the
>> neonasm
>>> patch to fix a different compile error with a missing instruction on the
>>> Pi.
>>>
>>> Has anybody encountered the ARM mode error mentioned below or know what I
>>> can do to push past it?
>>>
>>>
>>> $ git diff HEAD~1
>>> diff --git
>>> a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
>>> b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
>>> index e4002b8..37dcd75 100644
>>> --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
>>> +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
>>> @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts:
>>>   vadd.f32   s15, s15, s13
>>>   vadd.f32   s15, s15, s14
>>>   bls.done  @ if vector is multiple of 16 then finish
>>> - sbfx   r11, r1, #2, #1 @ check alignment
>>> +@ BH
>>>
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00234.html
>>> +@ sbfx   r11, r1, #2, #1 @ check alignment
>>> + mov  r11,#0
>>> + tst  r1,#4
>>> + movner11,#15
>>> +# BH END OF PATCH
>>>   rsbr9, r8, r3
>>>   andr11, r11, #3
>>>   movr6, r1
>>>
>>>
>>>
>>> $ cat /etc/debian_version
>>> 8.0
>>>
>>>
>>> $ uname -a
>>> Linux redwave 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l
>>> GNU/Linux
>>>
>>> $ gnuradio branch: master (82d0a6b)
>>> * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts .
>>> Swapnil Negi (HEAD, origin/master, origin/HEAD, master)
>>>
>>>
>>>
>>> Error output follows:
>>>
>>> [  0%] Building C object
>>> volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o
>>> In file included from
>>> /home/pi/gr/gnuradio/build/volk/lib/volk_machine_neon_hardfp_orc.c:130:0:
>>> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:
>> In
>>> function ‘volk_32fc_s32fc_multiply_32fc_neon’:
>>>
>> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:282:16:
>>> warning: unused variable ‘cPtr’ [-Wunused-variable]
>>>  lv_32fc_t* cPtr = cVector;
>>> ^
>>> /tmp/ccWuy8Qj.s: Assembler messages:
>>> /tmp/ccWuy8Qj.s:7707: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7718: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7725: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7732: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7740: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7747: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7754: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7761: Error: selected processor does not support ARM mode
>>> `rbit r4,r4'
>>> /tmp/ccWuy8Qj.s:7789: Error: selected processor does not support ARM mode
>>> `rbit ip,ip'
>>> volk/lib/CMakeFiles/volk_obj.dir/build.make:2572: recipe for target
>>> 'volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o'
>> failed
>>> make[2]: ***
>>> [volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o]
>> Error 1
>>> CMakeFiles/Makefile2:178: recipe for target
>>> 'volk/lib/CMakeFiles/volk_obj.dir/all' failed
>>> make[1]: *** [volk/lib/CMakeFiles/volk_obj.dir/all] Error 2
>>> Makefile:160: recipe for target 'all' failed
>>> make: *** [all] Error 2
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
> 

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

Re: [Discuss-gnuradio] Raspberry Pi 3 / Error: selected processor does not support ARM mode

[Philip Balister]

I'm not that familiar wit Raspian, but my impression is that it is
binary compatible with the original Pi, which has no neon support. The
volk code didn't handle this gracefully until recently.

That said, The Pi 3 does support neon and better. For the Pi-3, I'd use
something built to take advantage of the better processor.

Philip


On 05/08/2018 11:08 AM, Brad Hein wrote:
> On a new Raspberry Pi 3, running Raspbian, all apt-get package updates
> loaded, I'm encountering an error compiling gnuradio (branch: master). I
> made one modification from the default source code, and that is the neonasm
> patch to fix a different compile error with a missing instruction on the
> Pi.
> 
> Has anybody encountered the ARM mode error mentioned below or know what I
> can do to push past it?
> 
> 
> $ git diff HEAD~1
> diff --git
> a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> index e4002b8..37dcd75 100644
> --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts:
>   vadd.f32   s15, s15, s13
>   vadd.f32   s15, s15, s14
>   bls.done  @ if vector is multiple of 16 then finish
> - sbfx   r11, r1, #2, #1 @ check alignment
> +@ BH
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00234.html
> +@ sbfx   r11, r1, #2, #1 @ check alignment
> + mov  r11,#0
> + tst  r1,#4
> + movner11,#15
> +# BH END OF PATCH
>   rsbr9, r8, r3
>   andr11, r11, #3
>   movr6, r1
> 
> 
> 
> $ cat /etc/debian_version
> 8.0
> 
> 
> $ uname -a
> Linux redwave 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l
> GNU/Linux
> 
> $ gnuradio branch: master (82d0a6b)
> * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts .
> Swapnil Negi (HEAD, origin/master, origin/HEAD, master)
> 
> 
> 
> Error output follows:
> 
> [  0%] Building C object
> volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o
> In file included from
> /home/pi/gr/gnuradio/build/volk/lib/volk_machine_neon_hardfp_orc.c:130:0:
> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h: In
> function ‘volk_32fc_s32fc_multiply_32fc_neon’:
> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:282:16:
> warning: unused variable ‘cPtr’ [-Wunused-variable]
>  lv_32fc_t* cPtr = cVector;
> ^
> /tmp/ccWuy8Qj.s: Assembler messages:
> /tmp/ccWuy8Qj.s:7707: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7718: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7725: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7732: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7740: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7747: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7754: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7761: Error: selected processor does not support ARM mode
> `rbit r4,r4'
> /tmp/ccWuy8Qj.s:7789: Error: selected processor does not support ARM mode
> `rbit ip,ip'
> volk/lib/CMakeFiles/volk_obj.dir/build.make:2572: recipe for target
> 'volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o' failed
> make[2]: ***
> [volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o] Error 1
> CMakeFiles/Makefile2:178: recipe for target
> 'volk/lib/CMakeFiles/volk_obj.dir/all' failed
> make[1]: *** [volk/lib/CMakeFiles/volk_obj.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister]

On 04/02/2018 06:58 PM, Marcus D. Leech wrote:
> On 04/02/2018 06:09 PM, Philip Balister wrote:
>> On 04/02/2018 05:01 PM, MASDR GS wrote:
>>> I'm having issues with installing GNU radio using PYBOMBS. It
>>> successfully
>>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>>> missing python six message. I have been using this guide from Ettus for
>>> reference.
>>>
>>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>>>
>>>
>>>
>>> -- Python checking for six - python 2 and 3 compatibility library - not
>>> found
>>> CMake Error at volk/CMakeLists.txt:93 (message):
>>>    six - python 2 and 3 compatibility library required to build VOLK
>>>
>> Looks like the volk added a dependency on python-six and the E300 image
>> doesn't have it. Ettus needs to create a new file system image with that
>> package installed.
>>
>> Philip
> WHile that is actually, true, in this case the user is doing
> cross-builds on their PC host, and had installed python-six into their
> cross-build
>   environment, and still no joy.

Adding python-six-native cleared up my build issue. Likely the real
solution is regenerate the sdk including the native-sdk version of
python-six.

I'll poke meta-sdr for this soon to cover other users.

Philip

> 
> 
>>
>>> -- Configuring incomplete, errors occurred!
>>>
>>>
>>> Someone also posted the same issue but I couldn't find a response to his
>>> question along with how  to bypass this error. I've tried installing the
>>> lastest version of  python six-1.11.0 onto my local computer still but
>>> having no luck. Any guidance or help is appreciated.
>>>
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
>>>
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister]

On 04/02/2018 05:01 PM, MASDR GS wrote:
> I'm having issues with installing GNU radio using PYBOMBS. It successfully
> installs the SDK and UHD but once it reaches to GNU Radio I receive a
> missing python six message. I have been using this guide from Ettus for
> reference.
> 
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
> 
> 
> -- Python checking for six - python 2 and 3 compatibility library - not
> found
> CMake Error at volk/CMakeLists.txt:93 (message):
>   six - python 2 and 3 compatibility library required to build VOLK
> 

Looks like the volk added a dependency on python-six and the E300 image
doesn't have it. Ettus needs to create a new file system image with that
package installed.

Philip


> 
> -- Configuring incomplete, errors occurred!
> 
> 
> Someone also posted the same issue but I couldn't find a response to his
> question along with how  to bypass this error. I've tried installing the
> lastest version of  python six-1.11.0 onto my local computer still but
> having no luck. Any guidance or help is appreciated.
> 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Regarding the updating and extending gr-radar idea for GSoc 2018

[Philip Balister]

On 02/24/2018 08:34 AM, suraj hanchinal wrote:
> Hello Everyone,
> I am planning to apply for GSoc 2018. I was very interested and would love
> to work on the gr-radar toolbox. I was interested specifically in
> implementing passive-radar and multi-antenna support to gr-radar. Since a
> passive radar system would need a multi-antenna support anyways, I think
> they could be implemented together. I have been reading some research
> papers regarding passive radars to get a better understanding and I think
> implementing a passive radar to use FM transmitters nearby to locate
> objects as a good starting point and then turn to using wifi access points
> in an area as the next step. I am currently developing a proper write-up as
> well for the same. I would kindly request you to point out any things I
> should know of or just general suggestions on the subject. I would also
> kindly request the mentors Martin Braun and Stefan Wansch to enlighten me
> on this.


Also watch the Passive Radar talk from FOSDEM. Playlist here;

https://www.youtube.com/playlist?list=PLlhRHy4mKQlUrv76IIq72yF5WPbD9w_JG

Philip

> Thanking you,
> 
> Yours Sincerely
> Suraj Hanchinal
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

[Discuss-gnuradio] GNURadio BoF at FOSDEM

[Philip Balister]

I've arranged a room for a one hour BoF (Birds of a Feather) at FOSDEM.
Several GNU Radio developers will be on hand and we'd like a chance to
meet as many of you as possible and talk about the project.

The BoF is at 1200 Saturday in Room H.3227

Philip

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

Re: [Discuss-gnuradio] Project Call November Tomorrow!

[Philip Balister]

Is that Thursday or Friday?

On 11/15/2017 09:10 PM, Martin Braun wrote:
> Quick reminder that our montly project call is happening tomorrow, 10 AM
> Pacific, 19:00 CET, in the usual place.
> 
> Cheers,
> Martin
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

[Discuss-gnuradio] Embedded Workshop at GRCon 2017

[Philip Balister]

Friday of GRCon we have time for various topic workshops. We are in the
process of arranging those now, for people attending the conference
watch for an email with a survey and if you want an embedded one,
express interest.

What is a workshop? I don't want it to turn into another discussion of
things GNU Radio needs to be better in the embedded space. I don't ind
collecting some information, but what we really need to do is work out
how we can actually get some of these items done and how we can support
GNU Radio on emebedded systems better. My current interests are building
things with some of the cheap boards like Rpi-3 and I'm interested on
how we can do better testing of gnuradio on this sort of hardware.

These are my current interests. Bring yours and let's talk.

Philip

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

[Discuss-gnuradio] GNU Radio Coverity statis analysis

[Philip Balister]

As part of some GNU Radio infrastructure work, the Coverity static
analyses is running again. Thanks guys!

https://scan.coverity.com/projects/gnuradio

This is a great way to find places the code needs some work and a good
way to start contributing to the project. Go ahead and take a look!

Philip

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

Re: [Discuss-gnuradio] Audio issues on BBB

[Philip Balister]

On 05/29/2017 07:49 AM, Usman Haider wrote:
> Hi,
> 
> I am using GNU Radio on beaglebone black (BBB). I have transmitter and
> receiver flowgraph with audio sink audio source. When I run the flowgraphs
> on laptop or desktops I receive all the data packets correctly. But when I
> run either receiver or transmitter flowgraph on BBB there are intermittent
> packet drops. Packet loss is very small but it is there. There are no audio
> underruns or audio overruns. I am using a usb sound card with BBB.
> 
> I am using jessie 8.6 on BBB, GNU Radio version is 3.7.10.1. Enabled
> components are shown below
> 
> $ gnuradio-config-info --enabled-components
> python-support;testing-support;volk;gnuradio-runtime;gr-blocks;gnuradio-companion;gr-fft;gr-filter;gr-analog;gr-digital;gr-audio;*
> alsa;* oss;* jack;*
> portaudio;gr-channels;gr-noaa;gr-pager;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq
> 
> 
> Have anyone else tried using usb audio sound card on BBB with gnuradio
> before? Any idea what could be wrong? Thanks

Try using perf top to get an idea where the flowgraph hot spots are. The
BBB is a single core arm, so there isn't much processing power.

Philip


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

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

Re: [Discuss-gnuradio] gnuradio failing during pybombs install

[Philip Balister]

On 04/20/2017 01:29 PM, Jason Matusiak wrote:
> I was attempting to install the E310 cross-compile environment on a
> headless server and kept running into an error.  I have pybombs
> installed and all pertinent recipes added.  I run the command: pybombs
> prefix init ~/E310 -R e3xx-rfnoc -a e300
> 
> and it runs for a while before getting the following error (this is the
> end of the debug on the screen:
> qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such
> file or directory
> -- Found unsuitable Qt version "" from NOTFOUND
> -- QWT Version: 6.0.1

You are cross compiling, but it seems to have a broken path into the
sdk. Installing host dev libraries to fix problems isn't the right thing
to do since they are for x86 not arm.

I don't use pybombs, so can't help further :(

Philip

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

Re: [Discuss-gnuradio] Cross compile OOT cmake error

[Philip Balister]

On 04/05/2017 07:46 PM, Zach Hudson wrote:
> Perhaps I should explain that I am woefully uneducated on all of this.
> Could you point me to a good resource that could help me learn more
> about what I am getting myself into? Or is that toolchain something easy
> to install?

What is your target hardware? That would help narrow the focus of the
answer :)

Philip

> 
> Thanks
> Zach
> 
> On 04/05/2017 04:07 PM, Philip Balister wrote:
>> On 04/05/2017 06:54 PM, Zach Hudson wrote:
>>> I am using "../../gnuradio/cmake/Toolchains/oe-sdk_cross.cmake" as
>>> called out on the wiki page:
>>> https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target
>>>
>> That is the toolchain file. It expects you to install an OpenEmbedded
>> built toolchain and source an environment file.
>>
>> Philip
>>
>>
>>>
>>> Zach
>>>
>>> On 04/05/2017 03:39 PM, Philip Balister wrote:
>>>> On 04/05/2017 06:17 PM, Zach Hudson wrote:
>>>>> I am getting a cmake error when trying to follow the directions for
>>>>> cross compiling an OOT.
>>>>>
>>>>> CMake Error: Internal CMake error, TryCompile configure of cmake
>>>>> failed
>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- broken
>>>>> CMake Error at
>>>>> /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
>>>>> The C++ compiler "/usr/bin/c++" is not able to compile a simple
>>>>> test
>>>>> program.
>>>> /usr/bin/c++ isn't normally a cross compiler. What toolchain are you
>>>> trying to use?
>>>>
>>>> Philip
>>>>
>>>>> It fails with the following output:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> CMake will not be able to correctly generate this project.
>>>>> Call Stack (most recent call first):
>>>>> CMakeLists.txt:24 (project)
>>>>>
>>>>> I am able to compile it fine for local use. Any help would be
>>>>> appreciated.
>>>>>
>>>>>
>>>>> Zach Hudson
>>>>> Shine Micro
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Discuss-gnuradio mailing list
>>>>> Discuss-gnuradio@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>
> 
> 

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

Re: [Discuss-gnuradio] Cross compile OOT cmake error

[Philip Balister]

On 04/05/2017 06:54 PM, Zach Hudson wrote:
> I am using "../../gnuradio/cmake/Toolchains/oe-sdk_cross.cmake" as
> called out on the wiki page:
> https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target

That is the toolchain file. It expects you to install an OpenEmbedded
built toolchain and source an environment file.

Philip


> 
> 
> Zach
> 
> On 04/05/2017 03:39 PM, Philip Balister wrote:
>> On 04/05/2017 06:17 PM, Zach Hudson wrote:
>>> I am getting a cmake error when trying to follow the directions for
>>> cross compiling an OOT.
>>>
>>> CMake Error: Internal CMake error, TryCompile configure of cmake failed
>>> -- Check for working CXX compiler: /usr/bin/c++ -- broken
>>> CMake Error at
>>> /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
>>>The C++ compiler "/usr/bin/c++" is not able to compile a simple test
>>>program.
>>
>> /usr/bin/c++ isn't normally a cross compiler. What toolchain are you
>> trying to use?
>>
>> Philip
>>
>>>It fails with the following output:
>>>
>>>
>>>
>>>
>>>
>>>CMake will not be able to correctly generate this project.
>>> Call Stack (most recent call first):
>>>CMakeLists.txt:24 (project)
>>>
>>> I am able to compile it fine for local use. Any help would be
>>> appreciated.
>>>
>>>
>>> Zach Hudson
>>> Shine Micro
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
> 
> 

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

Re: [Discuss-gnuradio] Cross compile OOT cmake error

[Philip Balister]

On 04/05/2017 06:17 PM, Zach Hudson wrote:
> I am getting a cmake error when trying to follow the directions for
> cross compiling an OOT.
> 
> CMake Error: Internal CMake error, TryCompile configure of cmake failed
> -- Check for working CXX compiler: /usr/bin/c++ -- broken
> CMake Error at
> /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
>   The C++ compiler "/usr/bin/c++" is not able to compile a simple test
>   program.


/usr/bin/c++ isn't normally a cross compiler. What toolchain are you
trying to use?

Philip

> 
>   It fails with the following output:
> 
> 
> 
> 
> 
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:24 (project)
> 
> I am able to compile it fine for local use. Any help would be appreciated.
> 
> 
> Zach Hudson
> Shine Micro
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

[Discuss-gnuradio] Fwd: [NOTICE]: Apache Thrift Security Vulnerability CVE-2016-5397

[Philip Balister]

Control port users, take note.


 Forwarded Message 
Subject: [NOTICE]: Apache Thrift Security Vulnerability CVE-2016-5397
Date: Fri, 13 Jan 2017 12:16:04 -0500
From: Jake Farrell 
Reply-To: u...@thrift.apache.org, jfarr...@apache.org
To: u...@thrift.apache.org ,
d...@thrift.apache.org 

CVE-2016-5397

A security vulnerability was discovered in the Apache Thrift Go client
library,
CVE-2016-5397. It was determined that the Apache Thrift Go client library
exposed
the potential during code generation for command injection due to using an
external formatting tool. This has been traced and resolved in THRIFT-3893
[2].

Vendor: The Apache Software Foundation

Versions Affected: All Apache Thrift versions 0.9.3 and older may be
affected

Mitigation: Upgrading to the latest Apache Thrift 0.10.0 release

Resolution: The issue was resolved by removing the relevant calls to the
external
formatting tool, gofmt, since it is not required for core Apache Thrift code
functionality.

-Jake Farrell

[1]: CVE-2016-5397
[2]: https://issues.apache.org/jira/browse/THRIFT-3893


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

Re: [Discuss-gnuradio] gnuradio-companion binary not getting installed

[Philip Balister]

I think you need a python-devel package installed. Exact name will be
distro dependent.

Philip

On 11/29/2016 09:34 AM, Jason Matusiak wrote:
> This was really good information Seth, thanks.  I tried the steps
> Nicolas previously mentioned and I had the same problem.  I ran your
> commands and I see gnuradio-companion under the "disabled components" list.
> 
> Looking further up in the output, the thing I see different from your
> list is that I see:
> Dependency ENABLE_PYTHON = OFF
> 
> Why would that be?
> 
> Thanks!
> 
> On 11/28/2016 04:58 PM, Seth Hitefield wrote:
>> Something may have disabled gnuradio-companion in cmake.
>> Can you run: *"cd ~/gnuradio/src/gnuradio/build; cmake .."*?
>>
>> Towards the end of the output you should see:
>>
>> -- ##
>> -- # Gnuradio enabled components
>> -- ##
>>
>> and
>>
>> -- ##
>> -- # Gnuradio disabled components
>> -- ##
>>
>> Which one does gnuradio-companion fall under?
>>
>> You can also check the cmake output for the section where
>> gnuradio-companion is being configured.
>> That will give you an idea of what is going wrong if it is disabled.
>> It should look something like this:
>>
>> -- Configuring gnuradio-companion support...
>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> --   Dependency ENABLE_PYTHON = ON
>> --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>> --   Dependency CHEETAH_FOUND = TRUE
>> --   Dependency LXML_FOUND = TRUE
>> --   Dependency PYGTK_FOUND = TRUE
>> --   Dependency NUMPY_FOUND = TRUE
>> --   Enabling gnuradio-companion support.
>> --   Override with -DENABLE_GRC=ON/OFF
>>
>> -- Seth
>>
>>
>> On 11/28/2016 12:57 PM, Jason Matusiak wrote:
>>> I have a fresh install of Ubuntu 14.04 on a tablet and am trying to
>>> install gnuradio via pybombs.  I run "pybombs prefix init ~/gnuradio
>>> -a myprefix -R gnuradio-default" and it seems to complete
>>> successfully.  But if I look into gnuradio/bin, there is no
>>> gnuradio-companion.  Because of that, when I source setup_env.sh and
>>> tab out "gnur", the only thing that auto-completes is
>>> gnuradio-config-info.
>>>
>>> Any idea why the pybombs install acts like it worked, but I don't
>>> have a binary to run?
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] install gnu radio on angstrom

[Philip Balister]

On 10/15/2016 11:17 AM, Marcus Müller wrote:
> Hi Mehrad,
> 
> I'd say: without any error won't happen, but with a bit of trying, this
> should be possible.

How are you trying to install GNU Radio? What are the rros you are getting?

Philip

> 
> There should be a board support package for OpenEmbedded on Beagleboard
> XM (otherwise, you'll have to write one). Use that, together with
> balister's meta-sdr OE layer, and you should be able to build an OE
> image containing GNU Radio.
> 
> Notice that the Yocto build system / bitbake / the OE environment *does*
> have a learning curve, and it's not something that you master on the
> first try, but something that you learn by doing and reading docs.
> 
> Best regards,
> 
> Marcus
> 
> 
> On 15.10.2016 07:22, mehrad mirzaei wrote:
>> hello
>> I am new in OE and i need some basic help
>> how can i install gnu radio on beagleboard xm (default os angstrom)
>> without any error???
>> I will be thankful if anyone help me
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Using gr-ctrlport-monitor/gr-perf-monitorx remotely

[Philip Balister]

On 10/05/2016 11:37 AM, kyle.un...@l-3com.com wrote:
> We have a build of GNU radio with the ENABLE_PERFORMANCE_COUNTERS=ON and we 
> want to have a remote host (not the actual system running the flowgraph) run 
> gr-ctrlport-monitor and gr-perf-monitorx to show the performance data for a 
> given flowgraph.   I have read through the documentation, but it isn't clear 
> how to set this up.
> 
> Does someone know how to configure this?

I've done this in the past with the E310, but I forget the exact details :(

The Control Port page suggests it is possible:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort

Philip

> 
> Thanks,
> K-
> 
> W. Kyle Unice
> Staff Engineer
> MS F1H03
> 322 North 2200 West Dock 3
> Salt Lake City, Utah 84116-0850
> 
> Voice: 801-594-2687
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Updating SD Card Image on E310

[Philip Balister]

On 08/31/2016 10:40 AM, John B. Wood wrote:
> Hello, all.  From the Ettus website I recently downloaded and extracted
> the "sdimage-gnuradio-demo.direct" file from the "ettus-e3xx-sg1" folder
> (appropriate for my E310 SN).  I used dd to copy the image to a micro SD
> card without incident and installed it in the E310.  The E310 boots fine
> and I have no trouble logging in via SSH.  This release 4 image is
> supposed to have UHD 3.9.2 and GNU radio 3.7.9 but the only entries in
> my /home/root directory on the E310 are ".volk", ".bash-history" and
> .viminfo.  All the other GNU radio and GRC stuff that was present in
> /home/root in my previous SD card image is absent. What have I
> forgotten?  Thanks for any assistance you can provide.
> 
> 

GNURadio is installed in the usual place in /usr/.

Philip

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

[Discuss-gnuradio] Fwd: GRCon 2016 Dev Summit (Friday)

[Philip Balister]

Just a reminder, talk to me or Nathan if you have some ideas for useful
talks etc.

Philip


 Forwarded Message 
Subject: [Discuss-gnuradio] GRCon 2016 Dev Summit (Friday)
Date: Mon, 15 Aug 2016 17:14:45 +0100
From: Philip Balister <phi...@balister.org>
To: GNURadio Discussion List <Discuss-gnuradio@gnu.org>

The last day of the GNU Radio Conference will host a developers summit /
working day that is free and open to anyone interested in spending a day
collaborating with other GNU Radio developers and users. During the
summit we plan to have a series of very practical tutorials. The
tutorials will last between 15-30 minutes and focus on conveying "best
practices" used by GNU Radio developers and users with an emphasis on
knowledge that can be used during the developer summit.

If you are interested in attending, make sure you RSVP to the developers
summit through eventbrite [insert link].

If you are interested in presenting a tutorial send an email to
gr...@gnuradio.org with your tutorial idea. Examples of the kind of
tutorial we are looking for:

* Code walkthroughs to familiarize people with fixing their own pybombs,
gnuradio, volk issues
* Debugging GNU Radio (with gdb, pdb, valgrind, whatever tool you like)
* Managing multiple projects, installations, OOT projects

If you have ideas for short talks you believe would be interesting to
people, let us know and we can try and find a speaker.

Philip Balister and Nathan West

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


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

[Discuss-gnuradio] GRCon 2016 Dev Summit (Friday)

[Philip Balister]

The last day of the GNU Radio Conference will host a developers summit /
working day that is free and open to anyone interested in spending a day
collaborating with other GNU Radio developers and users. During the
summit we plan to have a series of very practical tutorials. The
tutorials will last between 15-30 minutes and focus on conveying "best
practices" used by GNU Radio developers and users with an emphasis on
knowledge that can be used during the developer summit.

If you are interested in attending, make sure you RSVP to the developers
summit through eventbrite [insert link].

If you are interested in presenting a tutorial send an email to
gr...@gnuradio.org with your tutorial idea. Examples of the kind of
tutorial we are looking for:

* Code walkthroughs to familiarize people with fixing their own pybombs,
gnuradio, volk issues
* Debugging GNU Radio (with gdb, pdb, valgrind, whatever tool you like)
* Managing multiple projects, installations, OOT projects

If you have ideas for short talks you believe would be interesting to
people, let us know and we can try and find a speaker.

Philip Balister and Nathan West

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

Re: [Discuss-gnuradio] Minimal install of GNU Radio without GUI, etc possible?

[Philip Balister]

On 08/05/2016 12:12 AM, Cinaed Simson wrote:
> On 08/04/2016 03:48 PM, Jason McHuff wrote:
>> Hello, I am building a Linux server running ClearOS (a CentOS 7.2 derivative
>> https://www.clearos.com/ ) and, among other things, want to use it to decode
>> and record calls on a P25 trunking system.
>>
>> I was able to successfully get trunk-recorder working with the GNU Radio
>> Live DVD (with great audio) and would like to get things permanently working
>> with Clear OS.  
> 
> Was this using op25?
> 
> I am wondering if it is possible to do a minimal install of
>> GNU Radio without any GUI stuff (Clear OS doesn't have a desktop) and just
>> what trunk-recorder needs to decode P25 using a RTL SDR.
> 
> I use the GUI to generate python code and then run the python code
> remotely via a SSH connection to a headless machine with a full install
> of gnuradio without using the GUI.
> 
> I presume it would be possible to build gnuradio without X11, Qt, or WX
> - but I've never tried it.

I've done it for an embedded build:

http://www.opensdr.com/posts/building-small-gnuradio-images/

You would need to work out what config options I fiddle with via the
PACKAGECONFIG line. But is definitely possible to build a usable
gnuradio without and gui parts.

Philip

> 
>>
>> I'm guessing GNU Radio 3.7.5.1-2.el7 which is available in the Clear OS
> 
> The current version is 3.7.10.1.
> 
>> repos is too old, and when I did try to install using PyBOMBS on it before I
>> ran into this issue with Apache Thrift
> 
> You don't need thrift - it's optional. I've never installed thrift and
> the builds complete - but I do have swig installed.
> 
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-06/msg00041.html
>> and the build-gnuradio script (I think) seemed to mess up the user database,
> 
> The email addresses pkconfig, automake and libtool issues - nothing
> about messing up a user database.
> 
>> and overall wouldn't mind doing things manually on a fresh install.
> 
> The nice thing about pybombs is it installs the dependencies - which is
> the hard part. Then you can setup your build environment. Typing mkdir
> build; cd build; cmake ../ is the easy part.
> 
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Displaying angle measurements with a nice GUI

[Philip Balister]

On 06/15/2016 01:06 PM, Nick Foster wrote:
> You ought to be able to use PyQwt's compass widget:

Qwt is OK, but please do not use PyQwt. It is unmaintained. See:

https://sourceforge.net/p/pyqwt/mailman/message/30352623/

Philip

> 
> http://qwt.sourceforge.net/class_qwt_compass.html
> 
> I used it for gr-air-modes and, while ugly, it does work. There's no
> integration into GRC so the Python to integrate the widget will, of course,
> be your responsibility.
> 
> --n
> 
> On Wed, Jun 15, 2016 at 9:45 AM Martin Braun  wrote:
> 
>> Meny,
>>
>> no, we don't. A compass was one of the suggestions for this year's GSoC,
>> but no one signed up for that.
>>
>> M
>>
>> On 06/15/2016 04:34 AM, Meny Sidar wrote:
>>> Hi guys
>>>
>>> I'm looking for a nice GUI that can plot my AoA calculations in a some
>>> kind of a compass looking GUI.
>>> Does anything like that exists? or do i have to build one of my own?
>>> Don't really know how, and would prefer not to start learning Python
>>> right now (on a deadline).
>>>
>>> Any help would be much appreciated!
>>> Thanks,
>>> Meny
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Alignment bug fix

[Philip Balister]

On 05/27/2016 09:43 AM, Robert McGwier wrote:
> Recently a kernel alignment bug was fixed (ugly) and this repaired the
> polyphase synthesis engine in the main code.

A fix in the Linux kernel? Or somewhere else. A reference to the commit
would be handy for people running across this issue.

Philip


> 
> My PhD student, Bill Clark (Amateur Radio call KK4EWQ) at Virginia Tech,
> has suffered with and pointed out this problem with the synthesizer for
> some time.
> 
> He wrote an out of tree module to correct the difficulty he was
> experiencing but we now believe this work is no longer needed.
> 
> Thanks for fixing the bug and thanks to Bill for his hard work at VT.
> 
> Bob McGwier
> Professor Electrical and Computer Engineering, VT
> N4HY
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] custom GR block for E310

[Philip Balister]

On 05/12/2016 08:06 AM, Jason Matusiak wrote:
>> If it's the only .so you need, and you put it in the right place, then
>> that works. Another way is to ssh mount your E310, then run make install
>> DESTDIR=/path/to/sshmount on your build machine (make sure paths match).
> 
> Martin, I was misunderstanding some things, but now I think I understand
> a bit better.
> I have done the make install of the ssh mount and the files seem to get
> put in the right
> places.  The problem now is that I can't seem to run my application that
> utilizes the
> library.  It feels like some sort of path needs to be updated since
> things got installed
> into lib/python/dist-packages/ (which didn't previously exist), but I
> can't seem to find
> any notes on this.  I know that the setup_env.sh on a normal machine
> handles all of this,
> but that doesn't exist on the E310.
> 
> Any thoughts of what step I am missing?
> 

Does this help?

http://gnuradio.org/redmine/projects/gnuradio/wiki/Cross_compile_an_OOT_and_install_on_target

Philip

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

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

Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[Philip Balister]

On 05/03/2016 10:47 AM, Sean Nowlan wrote:
> According to the wiki [1], ORC support was disabled on armhf due to a bug,
> which has apparently since been resolved [2]. Was ORC support added back
> for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
> page just out of date?
> 
> Thanks,
> Sean
> 
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
> [3] http://gnuradio.org/data/sdk/

I feel like we've replaced all the places we used orc, so we
(uhd/gnuradio/volk) are not really using it anymore.

It tends to show up in images, just that it may not be used by gnuradio
and friends.

Philip

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

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

Re: [Discuss-gnuradio] gnuradio embedded bitbake

[Philip Balister]

Did you resolve this?


Philip

On 04/23/2016 01:58 PM, Viktor Ivan Rodriguez Abdala wrote:
> Hi, I am working with gnuradio embedded for Zedboard, I got the
> following error with the bitbake error,
> 
> $ bitbake gnuradio-dev-image
> Loading cache: 100% |###| ETA: 
> 00:00:00
> Loaded 2190 entries from dependency cache.
> Parsing recipes: 100% |#| Time:
> 00:00:00
> Parsing of 1692 .bb files complete (1689 cached, 3 parsed). 2190
> targets, 100 skipped, 0 masked, 0 errors.
> ERROR: No recipes available for:
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/binutils/binutils-cross-canadian_2.23.2.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/qemu/qemu_1.7.0.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/gdb/gdb-cross_7.6.1.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-extended/libaio/libaio_0.3.109.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-extended/shadow/shadow_4.1.4.3.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-kernel/linux/linux-yocto_3.8.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-connectivity/openssl/openssl_1.0.1e.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/binutils/binutils-cross_2.23.2.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/binutils/binutils_2.23.2.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-kernel/linux/linux-yocto-tiny_3.8.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/gdb/gdb-cross-canadian_7.6.1.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/gdb/gdb_7.6.1.bbappend
> 
> /home/ivan/Embebido/oe-repo/oe-core/../meta-xilinx/recipes-devtools/binutils/binutils-crosssdk_2.23.2.bbappend
> 
> 
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
> There is any suggestion?
> 
> Regards,
> 
> Ivan Rodriguez
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] gnuradio Companion and Ettus E310, passing parameters

[Philip Balister]

I'm going to publish a test image with control port for the e310 next
week. I'm upstreaming the changes to OE now and and should be possible
to build GNU Radio with control easily "soon".

Philip

On 01/07/2016 03:30 PM, Tom Rondeau wrote:
> On Thu, Jan 7, 2016 at 11:25 AM, Mike Gilmer  wrote:
> 
>> I'm running gnuradio companion on Fedora.  I can make the Ettus device UDP
>> to gnuradio Companion and display RF. Great.
>>
>> Now, if possible, I'd like to be able to use the Companion GUI to pass, in
>> real-time, parameter changes, like center frequency, sample rate/bandwidth,
>> etc. to the embedded device.
>>
>> Is this possible?
>> Mike
>>
> 
> This is one of the exact use cases we developed ControlPort for. Right now,
> it's not going to be the easiest to use. I think Philip has gotten all of
> the support for ControlPort into OE at this point, but I'm not sure what it
> would take to update your E310 to enable this support right now (I did it
> myself, but that's a process...). Also, you'll need the most current GNU
> Radio to really support this. However, if you do get all set up with
> everything, there are some example scripts to help you out. See:
> 
> https://github.com/gnuradio/gnuradio/tree/master/gr-blocks/examples/ctrlport
> 
> The usrp_{source,sink}_controller.py code is a command-line program that
> connects to a running GNU Radio app with ControlPort enabled that allows
> you to set the parameters of a UHD source or sink. So you have an app
> running on your E310, you can use this to change the frequency, gain,
> antenna, etc.
> 
> This isn't the same as building something in GRC with sliders and such.
> You'll have to do more work than just that to get ControlPort to work that
> way for you.
> 
> Tom
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Pybombs and apache thrift help request

[Philip Balister]

On 01/02/2016 01:52 PM, Achilleas Anastasopoulos wrote:
> I had problems installing thrift myself.
> After consulting with the thrift forum i realized that thrift requires
> "trial" which is included in pythong package "twisted" (python-twisted).
> Unfortunately, thrift was failing silently...
> 
> After installing this package on fedora-22 (or 23?) the installation of
> thrift went fine.
> Somenone can update the pybombs recipie to install python-twisted as a
> prereq for thrift.

I can confirm you need to install twisted to get thrift going.

Philip

> 
> best
> Achilleas
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Projects using the USRP

[Philip Balister]

On 12/30/2015 07:25 AM, w xd wrote:
> Hi all,
> 
> Nowadays as we all konw,we can use USRP implement many interesting
> applications.Many company and university used our USRP.And the website
> www.gnuradio.org show us a good tutorial.
> 
>When I saw a similar instrument WARP and find they have a project
> website.And their website show many projects doing by WARP.Why our USRP
> don't  list many projects in our website www.gnuradio.org?I think add this
> part in our usrp website will benefit more people.
> 
> Just a little suggestion.

For GNU Radio specific projects:

http://www.cgran.org/

Philip


> 
> Thanks.
> 
> Best Regards
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] OOT module authors, please update your cmake

[Philip Balister]

On 12/29/2015 07:47 PM, Johnathan Corgan wrote:
> On Tue, Dec 29, 2015 at 4:42 PM, Michael Dickens 
> wrote:
> 
> 
>> No way to force things here, I don't think.
>>
> 
> To be clear, I was referring to new OOT modules created by gr_modtool.  Why
> would they need to have local copies of those files if they are already
> available via the installed GNU Radio?

Dunno, but gr-newmod (or whatever it is called) in gnuradio has a copy
of the files. I had to fix the issue twice.

Philip

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

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

[Discuss-gnuradio] OOT module authors, please update your cmake

[Philip Balister]

Per this commit in gnuradio:

https://github.com/gnuradio/gnuradio/commit/dec480ab3f0809677ba3ef2a3a64d402d742b5ec

This commit fixes the cmake in new OOT's, but existing ones need to do
this by hand.

Thanks,

Philip

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

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Philip Balister]

On 12/23/2015 01:43 PM, Richard Bell wrote:
> Yeah I should have clarified that. I tried the full package manager route
> of install about 2 years ago for gnuradio and uhd. It didn't work. I
> installed uhd through apt-get and gnuradio through apt-get with no success.
> 
> I'm just bringing that up so we don't assume that is an easy possibility
> for someone to do. As far as I know from my stab at it two years ago, it's
> not viable. Someone should try that route now to see if it is before we
> assume anything.

Fedora 23 has:

 uhd   x86_64   3.8.2-8.fc23
 gnuradio  x86_64 3.7.8.1-1.fc23

That said, "we" need to do a better job working with the major distro
packagers.

Also, the lack of versioning in most OOT's modules makes them difficult
to package for distro's.

Philip

> 
> On Wed, Dec 23, 2015 at 10:38 AM, Tim O'Shea  wrote:
> 
>> Ubuntu packages uhd
>> Assuming other oses do too
>> I'm sure there are up to date ppas somewhere too
>>
>>
>> On Wed, Dec 23, 2015, 1:34 PM Richard Bell 
>> wrote:
>>
>>> Is there a way for a new user to get uhd installed from the package
>>> manager though? A lot of people want to dive right into gnu radio with
>>> hardware, doing simple things like spectrum analysis. I'm not aware of a
>>> way of getting the uhd + gnuradio setup running that's easier then pybombs.
>>> I very well could be wrong here.
>>>
>>> On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea 
>>> wrote:
>>>
 Most new users should be installing gnu radio binaries via their os
 package manager repos or ppa.   Pybombs should be used for 1. Helping get
 up to date oot modules set up and deployed ( like pip ) and 2. Helping
 developers set up their development environment.
 So I'm not sure installer is the right idea to impart on new users at all


 On Wed, Dec 23, 2015, 1:23 PM Richard Bell 
 wrote:

> I'd like to throw in another point from an entry level perspective.
> Those people who might need pybombs most, are those who need names that
> tell them what it's for the most. Even if it is incorrect to call pybombs
> an installer, it would really help the entry level folks (which I would
> claim without support is the largest population of the community at any
> given time) understand what it's for and how they should use it. I think 
> we
> all have the experience of learning new tools and running into tool names,
> which even though the description is spot on for what its for, at the time
> carried zero value for the new guy using it (thinking mostly about Xilinx
> tool names here).
>
> With that said, I think it would be good for the community to use the
> word installer in the tool that makes gnuradio and uhd really easy to
> install, and is what the vast majority of people I'm guessing would use it
> for.
>
> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun 
> wrote:
>
>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>>> I don't want to destroy your idea, but GRAB sounds like CRAP as well
>> and
>>> you can think of the associated sentences ;)
>>
>> 'grab' is also a very common english verb, so I think people would be
>> able to distinguish. It also sounds like 'crab' if you like :)
>>
>> M
>>
>>>
>>> On 12/22/2015 09:31 PM, Richard Bell wrote:
 GRAB = Gnu RAdio Basic installer

 Then we can say things like "Go GRAB it" when referring to a needed
>> module

 On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <
>> martin.br...@ettus.com>
 wrote:

> There's been some demand to rename PyBOMBS, and now that we're
> re-releasing it, this is a good time to think about it. Complaints
>> about
> the name include:
>
> - It may or may not be true that people have been detained by TSA
>> for
> working on PyBOMBS at the airport[1]
> - The name suggests a Python-related packages (like Pylint,
>> PyPI...)
> rather than a GNU Radio-related tool
> - People can't agree on a capitalization
> - No one can remember what the acronym stands for
>
> Sure, this is not a critical thing, but now's a good chance to
>> bring it
> up and also, this is not a joke :)
>
> Here's how we're going to do this:
>
> - Please suggest new names in this thread.
> - I will choose from those names based on 'can I live with this
>> name',
> 100% subjectively.
> - New names will be put up for a vote. This will include an option
>> to
> keep the old name.
> - Finally, the result of the vote will be used as a strong
>> suggestion on
> what the new name will be.
>

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Philip Balister]

YABS - Yet Another Build System

On 12/22/2015 03:37 PM, Chris Kuethe wrote:
> The only strong opinion I have is an objection to the substring "rpm" due
> to potential confusion with existing RPM installation utilities.
> 
> GRAB is nice. GRMM too.
> 
> Other possibilities are GRIP/GRIM: GnuRadio Installation and
> Packages/Modules
> 
> 
> 
> On Tue, Dec 22, 2015 at 12:31 PM, Tim  wrote:
> 
>> Martin,
>> Excited to see pybombs2 emerging as stable !
>> A few thoughts on the naming below --
>> -Tim
>>
>> On 12/22/2015 03:10 PM, Martin Braun wrote:
>>> There's been some demand to rename PyBOMBS, and now that we're
>>> re-releasing it, this is a good time to think about it. Complaints about
>>> the name include:
>>>
>>> - It may or may not be true that people have been detained by TSA for
>>> working on PyBOMBS at the airport[1]
>>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>>> rather than a GNU Radio-related tool
>> it doesn’t really need to be gnu radio specific --
>> it was written to work with any such light weight recipes that follow
>> standard git/cmake or other common or custom format
>>
>>> - People can't agree on a capitalization
>>> - No one can remember what the acronym stands for
>>>
>>> Sure, this is not a critical thing, but now's a good chance to bring it
>>> up and also, this is not a joke :)
>>>
>>> Here's how we're going to do this:
>>>
>>> - Please suggest new names in this thread.
>>> - I will choose from those names based on 'can I live with this name',
>>> 100% subjectively.
>>> - New names will be put up for a vote. This will include an option to
>>> keep the old name.
>>> - Finally, the result of the vote will be used as a strong suggestion on
>>> what the new name will be.
>>>
>>> There already have been some suggestions:
>>>
>>> - gromit -- the GNU Radio out-of-tree module installation tool
>> this name makes me cringe horribly
>> "installation tool" isn't really a fair characterization since it is
>> setting up a development environment
>> apt-get or standard binary installs are more "installation tool"
>>
>>> - the groot
>> also - horrible cringe factor,
>>
>>> - grpm -- the GNU Radio package manager
>> I like grpm --
>> other similar possibilities:
>>
>> rmm - radio module manager
>> grmm - gnu radio module manager
>> gmm - gnuradio module manager
>> spm - SDR Packager Manager
>> spm - spm package manager
>>
>> personally in favour of something short and functional vs cutesy and
>> contrived (we already have one of those names)
>> three letter package managers seem to be relatively common practice in FOSS
>>
>> examples:apt, rpm, pip, gpm, npm, ...
>>
>>>
>>>
>>> OK guys, bring up the ideas!
>>>
>>> Cheers,
>>> Martin
>>>
>>> [1] It's not.
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/17/2015 10:42 AM, Jason Matusiak wrote:
>> Arg, I forgot you are using rfnoc :) Sorry.
>> The latest e310 files with rfnoc are here:
>> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/
>> You could also update the release-3 image to have rfnoc also.
> 
> So here is where things ended up.  The default E310 load from OCT (in
> the link above) doesn't seem to work with the "RFNOC: Radio" block in
> the most recent GR.  In particular the set_rx_dc_offset attribute seems
> to be missing from the load on the E310.
> 
> What I ended up doing was to update the E310 with an updated
> cross-compiled build via pybombs.  The following are the steps I took in
> case it helps someone:
> *mkdir ~/E310
> *sshfs -o allow_root root@192.168.1.111:/ ~/E310
> 
> Now I have a folder that is linked to the E310.  Next I update UHD with:
> *.
> /usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
> * cd ~/pybombs/src/uhd/host/
> *mkdir build-arm && cd build-arm
> *cmake
> -DCMAKE_TOOLCHAIN_FILE=/home/jason/pybombs/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_E300=ON -DCMAKE_INSTALL_PREFIX=/usr ..
> *make -j4
> *sudo make install DESTDIR=~/E310
> 
> Then to update gr-ettus I:
> *cd ~/pybombs/src/gr-ettus/
> *mkdir build-arm && cd build-arm
> *cmake
> -DCMAKE_TOOLCHAIN_FILE=/home/jason/pybombs/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr ..
> *make -j4
> *make install DESTDIR=~/E310
> 
> I then rebooted the E310 and my python script with the set_rx_dc_offset
> doesn't seem to cause an issue anymore.  If there are some simpler steps
> to my convoluted update setup, please let me know.

I'll add updating the rfnoc test images for the E310 to my todo list.

Philip

> 
> ~Jason
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/13/2015 08:37 AM, Jason Matusiak wrote:
>> The release-3 (and newer) toolchains have mako. Anything older doesn't.
>> That's the first thing to check.
> 
> Thank you Philip.  What is the best way to do that?  I tried looking at
> the version-armv7ahf-vfp-neon-oe-linux-gnueabi only shows:
> Distro: nodistro
> Distro Version: nodistro.0
> Metadata Revision: 93d79fc162bd49387958e9e4d898dc4ba50d20b0
> Timestamp: 20150110021354
> 

Also the timestamp suggests the sdk was built on Jan 10, 2015. I'm
having trouble matching that to a release image. Release-3 was upload in
July, so sdk's made before then likely will not have mako.

As always, the sdk should match the image you use in the E310.

Philip

> 

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/13/2015 08:37 AM, Jason Matusiak wrote:
>> The release-3 (and newer) toolchains have mako. Anything older doesn't.
>> That's the first thing to check.
> 
> Thank you Philip.  What is the best way to do that?  I tried looking at
> the version-armv7ahf-vfp-neon-oe-linux-gnueabi only shows:
> Distro: nodistro
> Distro Version: nodistro.0
> Metadata Revision: 93d79fc162bd49387958e9e4d898dc4ba50d20b0
> Timestamp: 20150110021354
> 
> 

Hmm, need to look inside the SDK to figure this out 

How about running

which python

to make sure you are using the sdk python, then

python

and

import mako

if that succeeds the sdk has python.

Philip

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/13/2015 10:43 AM, Jason Matusiak wrote:
> Thank you Philip.  I blew away my old toolchain, re-grabbed the latest
> and installed it.  I can then run the cmake, make, and make install to
> load up the SD card on the E310 without error.
> 
> Sadly, it doesn't appear to be 100% right because if I run a python
> script I created in GRC on my PC, I get:
> root@ettus-e300:~# python RFNOCtest2.py Traceback (most recent call
> last):
>   File "RFNOCtest2.py", line 12, in 
> from gnuradio import uhd
>   File "/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line
> 135, in 
> _prepare_uhd_swig()
>   File "/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", line
> 38, in _prepare_uhd_swig
> import uhd_swig
>   File "/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line
> 28, in 
> _uhd_swig = swig_import_helper()
>   File "/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", line
> 24, in swig_import_helper
> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
> ImportError: libuhd.so.003: wrong ELF class: ELFCLASS64
> 
> Which looks like something is not cross compiling properly.  Am I
> missing something in pybombs to get libuhd to build properly when doing
> my crosscompile in uhd/host/build-arm?
> 

Assuming you are using Release-3 on the E310, make sure the sdk and file
system image come from the same directory. The error looks like this is
not the case.

There is a file on the image /etc/version that has a timestamp in it.
This should be close to the one in the sdk.

Philip

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/13/2015 11:37 AM, Jason Matusiak wrote:
>> Assuming you are using Release-3 on the E310, make sure the sdk and file
>> system image come from the same directory. The error looks like this is
>> not the case.
> Are you saying Release-3 for the cross-compiler (I was assuming so)? And
> for the directory do you mean on the ettus file page?

Note the directory contains the file system and sdk.

http://files.ettus.com/e3xx_images/e3xx-release-3/

Philip

> 
>> There is a file on the image /etc/version that has a timestamp in it.
>> This should be close to the one in the sdk.
> I'll double check it. Thanks.
> 

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/13/2015 03:15 PM, Jason Matusiak wrote:
>> Note the directory contains the file system and sdk.
> 
>> http://files.ettus.com/e3xx_images/e3xx-release-3/
> 
> Philip, That wasn't the directory I was using on the site, so thank you.
>  It seems like gr-ettus is not in the build by default, is that by
> design?  At this point I assume that I need to cross-compile and install
> it onto there?
> 

Arg, I forgot you are using rfnoc :) Sorry.

The latest e310 files with rfnoc are here:

http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/

You could also update the release-3 image to have rfnoc also.

Sorry for the confusion.

Philip

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

Re: [Discuss-gnuradio] pybombs cross-compile mako error

[Philip Balister]

On 11/13/2015 08:09 AM, Jason Matusiak wrote:
> I am having an issue with a cross compile (which I haven't done in a
> while) for my E310 and failing on Mako w/n pybombs.

The release-3 (and newer) toolchains have mako. Anything older doesn't.
That's the first thing to check.

Philip

> 
> 
> if I go to: ~/pybombs/src/uhd/host/build-arm
> and run: .
> /usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
> followed by: cmake
> -DCMAKE_TOOLCHAIN_FILE=/home/jason/pybombs/src/uhd/host/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_E300=ON -DCMAKE_INSTALL_PREFIX=/usr ..
> 
> I get:
> -- The CXX compiler identification is GNU 4.9.1
> -- The C compiler identification is GNU 4.9.1
> -- Check for working CXX compiler:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
> -- Check for working CXX compiler:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
> -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working C compiler:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
> -- Check for working C compiler:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
> -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> 

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

Re: [Discuss-gnuradio] usrp->get_rx_sensor_names() @ettus-b210 and ettus-E310

[Philip Balister]

On 11/09/2015 08:44 AM, Daniele Disco wrote:
> I tried to use 
> http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
> 
> But during the execution of cmake -DCMAKE_TOOLCHAIN_FILE=etc. etc. etc.
> The procedure fails because in this case the sw does not found  make
> (Python checking for Mako templates 0.4 or geater - "import mako" faild)
> And the Makefile is not built.

A couple of quick notes.

1) Use only the toolchain that matches the image you are using on your
e310. At this point use Release-3. (I see from this email you tried
release-2 which doesn't have mako, but see next point)

2) The toolchain already has uhd installed in it, so you do not need
compile uhd.

3) Try compiling a small program that initializes uhd and see if you can
get that working.

Philip

> 
> BR
> Daniele
> 
> 
> _
> Telecom Italia | TIM
> 
> Daniele Disco
> Engeenering & Tilab - Wireless Access
> Wireless Innovation
> Via Reiss Romoli, 274 - 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
> Fax. +39 06 4186 5196
> Tim Official: Facebook - 
> Twitter
> www.tim.it
> 
> From: Marcus Müller-3 [via GnuRadio] 
> [mailto:ml-node+s4n56822...@n7.nabble.com]
> Sent: lunedì 9 novembre 2015 11:31
> To: Disco Daniele
> Subject: Re: usrp->get_rx_sensor_names() @ettus-b210 and ettus-E310
> 
> Hi Daniele,
> 
> that's a crash. I'm including usrp-users (because this is not inherently
> related to GNU Radio, that might be the best place to discuss this);
> follow up on either list, as you deem correct.
> 
> so, get_rx_sensor_names seems to crash. Hm; as I don't have an E310
> right at hand, I can only read the source code, and from that, I'm not
> quite sure why UHD would fail to find the rx frontend tree it tries to
> access in get_rx_sensor_names. First sanity check: the version of UHD
> you used to cross-compile is the same as running on the E310, right?
> 
> I think this might be easiest to debug if you did the two things:
> 
> on your PC with B210:
> uhd_usrp_probe --tree > b210.property_tree.txt
> on your E310:
> uhd_usrp_probe --tree > e310.property_tree.txt
> 
> and share both files.
> 
> Best regards,
> Marcus
> 
> 
> On 09.11.2015 09:41, Daniele Disco wrote:
> 
>> The error is "Segmentation fault"
>>
>>
>>
>> --
>> View this message in context: 
>> http://gnuradio.4.n7.nabble.com/usrp-get-rx-sensor-names-ettus-b210-and-ettus-E310-tp56815p56818.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> Discuss-gnuradio mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://gnuradio.4.n7.nabble.com/usrp-get-rx-sensor-names-ettus-b210-and-ettus-E310-tp56815p56822.html
> To unsubscribe from usrp->get_rx_sensor_names() @ettus-b210 and ettus-E310, 
> click 
> here.
> NAML
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
> abbiate ricevuto questo documento per errore siete cortesemente pregati di 
> darne immediata comunicazione al mittente e di provvedere alla sua 
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged 
> information intended for the addressee(s) only. Dissemination, copying, 
> printing or use by anybody else is unauthorised. If you are not the intended 
> recipient, please delete this message and any attachments and advise the 
> sender by return e-mail, Thanks.
> 
> [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è 
> necessario.
> 
> 
> 
> logo Ambiente_foglia2.jpg (928 bytes) 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> 

Re: [Discuss-gnuradio] Ettus E310 FM Radio

[Philip Balister]

On 11/09/2015 11:02 AM, John B. Wood wrote:
> On 11/06/2015 02:27 PM, Ron Economos wrote:
>> There is a stereo FM receiver in gr-rds. If you delete the RDS
>> specific blocks in the example flow graph (gr-rds/apps/rds_rx.grc),
>> you don't even have to compile gr-rds.
>>
>> https://github.com/bastibl/gr-rds
>>
>> Ron
> Thanks for that link, Ron.  The person who constructed rds_rx_grc
> certainly expended some effort, IMO.  The flow graph is considerably
> more involved than the wideband FM (monaural) receiver example that
> comes packaged with GRC.  I deleted the RDS blocks and this modified
> flow graph does work with the E310.  The fidelity of the audio would be
> very good except there's a lot of noise coming through.  I don't have
> this with the mono example.  There may be some opportunity for noise
> clean-up once I absorb what's going on with the flow diagram. Sincerely,

I wonder if the gain setting needs adjusting for the E310?

Philip

> 
> 
> John B. Wood
> U.S. Maval
> Research Laboratory
> Code 5520
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] On the "right" approach for developing applications to be run on an E310

[Philip Balister]

On 11/06/2015 08:06 AM, Daniele Disco wrote:
> HI Marcus!
> I followed yours suggestions but what is the right way to cross compile a
> new applications?
> At the moment I found a "dirty" shortcut using the uhd library:
> I add my application in the examples directory of uhd library; I modify the
> CMakeLists.txt in the directory examples and make "all" the procedure to
> rebuild uhd library for arm.
> 
> There is a way more agile to get the same results?

I have some info on cross compiling for gnuradio here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded#Common-development-tasks

The process should be similar for non GNU Radio work also.

Philip

> 
> TIA
> Daiele
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p56778.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] On the "right" approach for developing applications to be run on an E310

[Philip Balister]

On 11/06/2015 12:36 PM, West, Nathan wrote:
> You can compile simple programs very similarly to how you normally use
> gcc/g++. Source the OE SDK, then call CC or CXX. The environment script
> exports these variables the way you would expect if you're familiar with
> cross compiling at all. You *could* just call arm-oe-linue-gnueabi, but you
> probably shouldn't.

Source the toolchain environment file. Reading it will give you an idea
of how things should be called.

Philip


> 
> For simple applications it's not too bad. Beyond a toy program or two
> you'll really want to start using cmake. It's also important to note that
> when you run a command line like that yourself you're probably missing out
> on a bunch of optimizations and options that you otherwise take for granted.
> 
> On Fri, Nov 6, 2015 at 10:45 AM, Daniele Disco <
> daniele.di...@telecomitalia.it> wrote:
> 
>> Thank you Philip but I was thinking to a "simpler" procedure like
>> gcc-arm app.cpp -luhd -letc. -letc. -o app
>>
>> It is possible avoid the cmake passage?
>>
>> Daniele
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p56786.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] Estimate CPU usage

[Philip Balister]

On 11/06/2015 03:54 PM, haroldmk wrote:
> Hello all, 
> 
> I am working with GNU Radio on a Zedboard (which is a Xilinx Zynq-7000 based
> device). The linux dist. used is the one from this page:
> http://gnuradio.org/data/sdk/zedboard_armv7a-sf-vfp-neon/
> 
> I have described some functions on the FPGA of the Zynq and I am able to
> send and receive data from a gnuradio .py , and everthing seems to be
> working ok. 
> 
> I would like to measure how the use of the FPGA impacts the CPU performance,
> I am thinking on measuring the % of CPU usage of a GNU Radio block that
> performs all the calculations only in the ARM processor and the same
> function but co-processing some data in the FPGA.
> 
> The problems that I have in doing that measure is that the Linux dist. used
> has no graphical interface and only one command line, so, I am not able to
> run the .py file on one termianl and other programm on other terminal like
> TOP for CPU usage measurement.
> 
> I tried with a bash script but when I execute the .py file it "blocks"
> everthing. I have to manually press enter or stop the process, depending on
> run option I chose initially in the flow graph options, "Generate Options:
> No GUI" and "Run Options: Prompt to exit" or "Run to completion".

Use ssh to login via the network.

perf and friends can be really handy for understanding what the
processor is doing.

https://www.youtube.com/watch?v=kWnx6eOGVYo

Philip

> 
> Any ideas on how to handle this?.
> Thanks in advance.
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Estimate-CPU-usage-tp56794.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] GRCon15 statistics

[Philip Balister]

On 09/09/2015 02:22 PM, Francisco Albani wrote:
> Oops!
> 
> I may have misused the word 'assisted'. I wished to mean 'attended' (I'm
> expecting a number around 200).

English is a tricky language.

Even better, how about a graph of attendance at each GRCon?

Philip

> 
> Sorry and thanks!
> 
> 2015-09-09 11:22 GMT-03:00 Tom Rondeau :
> 
>> On Wed, Sep 9, 2015 at 9:28 AM, Michael Dickens >> wrote:
>>
>>> Hi Francisco - I'm not sure we can definitely say how many people helped
>>> out; we sort of ebbed and flowed as necessary to make it work. There were
>>> another 2-6 of us meeting weekly (and emailing regularly) for
>>> organizational purposes; some more often than others. We had 15-20
>>> volunteers to help with registration, setup, posters, booths, etc... Some
>>> of the sponsors (e.g., Ettus & DRS) helped out in various ways that were
>>> not required of them, sort of as volunteers. Then there were the caterers &
>>> venue folks, and the sponsors had their own helpers internal to each's
>>> respective company. So, just guessing from the above numbers I'd say
>>> something like 30-35 people had their hands in making sure GRCon15 came off
>>> smoothly. Hope this helps! - MLD
>>>
>>> On Tue, Sep 8, 2015, at 07:05 PM, Francisco Albani wrote:
>>>
>>> I'm curious about how many people assisted to the all the annual
>>> conferences, specially to the last one. And maybe there are more
>>> interesting statistics to know.
>>>
>>>
>> Also,because I wanted to give the people that helped out credit:
>>
>> http://www.trondeau.com/grcon15-organizing-committee/
>>
>> Tom
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

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

Re: [Discuss-gnuradio] 3.7.8 build problem 'cannot find -lcblas'

[Philip Balister]

Install blas, lapack or something that supplies the missing library.

Philip

On 08/18/2015 12:54 AM, Barry Jackson wrote:
 Ping?
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

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

[Discuss-gnuradio] Looking for photos of embedded systems running GNU Radio

[Philip Balister]

I'd like to get some photos of Embedded systems running GNU Radio for
the Embedded WG poster at GR Con. These can be as simple as a dev board
and a USRP or other digitizer to interesting systems.

Philip

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

Re: [Discuss-gnuradio] Cross compile GNU Radio fail

[Philip Balister]

Anyone have any thoughts on this? I'm on vacation and can't try this.

Philip

On 07/14/2015 07:31 AM, shaunwang wrote:
 Hello, 
 
 I tried to follow the GNURadio cross compile instruction in this website, 
 https://gnuradio.org/redmine/projects/gnuradio/wiki/Cross_compile_GNU_Radio_and_install_on_target
 
 I used this cmake command
 cmake -Wno-dev \
-DCMAKE_TOOLCHAIN_FILE=../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 ../
 
 but it gives me this error message
 Scanning dependencies of target gr_trellis_html
 [ 90%] Generating gr-trellis.html
 xmlto: /home/shaunwang/Documents/GNURadio
 source2/gr-trellis/doc/gr-trellis.xml does not validate (status 1)
 xmlto: Fix document syntax or use --skip-validation option
 warning: failed to load external entity test_tcm.py.xml
 /home/shaunwang/Documents/GNURadio
 source2/gr-trellis/doc/gr-trellis.xml:481: parser error : Failure to process
 entity test_tcm_listing
 test_tcm_listing;
   ^
 /home/shaunwang/Documents/GNURadio
 source2/gr-trellis/doc/gr-trellis.xml:481: parser error : Entity
 'test_tcm_listing' not defined
 test_tcm_listing;
   ^
 warning: failed to load external entity test_viterbi_equalization1.py.xml
 /home/shaunwang/Documents/GNURadio
 source2/gr-trellis/doc/gr-trellis.xml:693: parser error : Failure to process
 entity test_viterbi_equalization1_listing
 test_viterbi_equalization1_listing;
 ^
 /home/shaunwang/Documents/GNURadio
 source2/gr-trellis/doc/gr-trellis.xml:693: parser error : Entity
 'test_viterbi_equalization1_listing' not defined
 test_viterbi_equalization1_listing;
 ^
 make[2]: *** [gr-trellis/doc/gr-trellis.html] Error 11
 make[1]: *** [gr-trellis/doc/CMakeFiles/gr_trellis_html.dir/all] Error 2
 make: *** [all] Error 2
 
 
 Is there anyone who can help me with this? Thanks!
 
 Shaun
 
 
 
 --
 View this message in context: 
 http://gnuradio.4.n7.nabble.com/Cross-compile-GNU-Radio-fail-tp54771.html
 Sent from the GnuRadio mailing list archive at Nabble.com.
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

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

Re: [Discuss-gnuradio] Cross compile GNURadio on ARM in Odroid XU3

[Philip Balister]

I'm trying not to get drug into this thread sine I am on vacation next
week ...

xu3 - https://github.com/akuster/meta-odroid or
https://github.com/ARM-software/meta-mali ?

The ARM-software one looks interesting since it may deal with the Mali
stuff. I'll try and get some time to build test it on our layer stack we
use for GNU Radio.

I have a (discontinued) XU and am annoyed at hardfloat not supporting
the lcd panel I bought for it on the XU3. So I can't test XU3 locally.

The big problem in the low end arm dev board space is the matrix of
random vendor kernels, crappy binary only images from vendors (GPL
compliance nightmares for people selling products), short lived
hardware, multiple desktop distros with even more quirks and so on. The
support envelope for GNU Radio on ARM is huge. I cannot be handled by a
small group of people without setting some boundaries.

Donations of cash/bitcoins welcome :) I already have too many
interesting borads to play with.

Philip

On 07/09/2015 02:00 AM, shaunwang wrote:
 Hello Nathan
 
 Firstly I am really grateful for your long suggestions. I am very surprised
 to spend so much time writing this for me.
 
 Secondly, I already tried building GNU Radio natively in Odroid xu3 and
 Hummingboard. They both took long time to build. And I always meet some
 bugs, but I fixed them. Building GNU Radio on Hummingboard is definitely a
 pain. 
 
 I want to concentrate on cross compile now even I have native compile
 option. I am reading Open Embedded website now, OE layer does not support
 Odroid XU3 layer. 1What do you mean for add support? 2I am going to try
 Tom's rootfs and chroot once I understand it. 3 Is this the website you are
 talking about for cross compile with OE
 https://github.com/balister/meta-sdr/wiki/CrossCompile. 
 the first three steps are
 1)Build the cross toolchain with OpenEmbedded:
 bitbake -c populate_sdk gnuradio-dev-image
 a
 2)Find the sdk:
 $ ls tmp-eglibc/deploy/sdk/
 oecore-x86_64-armv7a-vfp-neon-toolchain-nodistro.0.sh
 
 3)Install the sdk:
 '$ sudo sh
 tmp-eglibc/deploy/sdk/oecore-x86_64-armv7a-vfp-neon-toolchain-nodistro.0.sh`
 
 But the problem is that this SDK file is for Zynq chip.
 http://gnuradio.org/data/sdk/zedboard_armv7a-sf-vfp-neon/
 
 Do you have any idea how to build SDK for ARMV7L which is used in Odroid
 xu3? 
 
 According to my understand of reading in GNURadio website, it seems the
 number 3) way is the same way as get an SDK for my distribution. I read from
 this website https://gnuradio.org/redmine/projects/gnuradio/wiki/OE_PyBOMBS 
From what you said, it seems I can either combine OE and SDK to do cross
 compile or JUST use SDK for my distribution. I have not found any resource
 for the later option. Since you said the later option is unknown and hard, I
 will save this for later.
 
 I am going to try the Tom's rootfs way and OE SDK way firstly, I will keep
 posting my questions, thank you so much for your time and help. I am super
 grateful!
 
 Shaun
 
 
 
 --
 View this message in context: 
 http://gnuradio.4.n7.nabble.com/Cross-compile-GNURadio-on-ARM-in-Odroid-XU3-tp54685p54709.html
 Sent from the GnuRadio mailing list archive at Nabble.com.
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 

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

Re: [Discuss-gnuradio] Cross compile GNURadio on ARM in Odroid XU3

[Philip Balister]

On 07/08/2015 08:52 AM, Sid Boyce wrote:
 Forgot to ask - Why cross-compile when you have something as powerful as
 an  ODROID-XU3?
 
 I dislike cross compiling and even built gnuradio on a Beaglebone White
 with just the SDR card some time ago.

It is still way faster. Also, you avoid the OOM killer that trips up so
many people.

Philip

 
 I have 2 USB 2.5 inch hard drives on the ODROID-U3 to give me more than
 adequate space to build all sorts.
 Konsole output
 root@odroidu3:~# fdisk -l
 
 Disk /dev/mmcblk0: 62.7 GB, 62730010624 bytes
 4 heads, 16 sectors/track, 1914368 cylinders, total 122519552 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x000c4046
 
Device Boot  Start End  Blocks   Id  System
 /dev/mmcblk0p13072  266239  1315846  FAT16
 /dev/mmcblk0p2  266240   12251955161126656   83  Linux
 
 Disk /dev/sda: 500.1 GB, 500107862016 bytes
 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x6045b0b4
 
   Device Boot  Start End  Blocks   Id  System
 /dev/sda1   *2048   820314547   410156250   83  Linux
 /dev/sda2   820314548   97677316778229310   82  Linux swap /
 Solaris
 
 Disk /dev/sdb: 500.1 GB, 500107862016 bytes
 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x000127ef
 
   Device Boot  Start End  Blocks   Id  System
 /dev/sdb1   *20486291660731457280   83  Linux
 /dev/sdb262916608   97200   454541696+  83  Linux
 /dev/sdb3   97201   976773167 2386583+  82  Linux swap /
 Solaris
 root@odroidu3:~#
 73 ... Sid.
 
 On 08/07/15 12:11, shaunwang wrote:
 Hello Dennis

 Thank you so much for giving me many information. I never seen a building
 way which combines binary file and source file of GNURadio. Do you
 have the
 website that gives all instructions?

 The OpenEmbedded and PyBOMBS way is very confusing. I read this website
 https://gnuradio.org/redmine/projects/gnuradio/wiki/OE_PyBOMBS. But it is
 very confusing. I even cannot find all the files it talks about. You said
 you had to customize some CMAKE files, but did you make it work? Could
 you
 tell me how you exactly did it?

 For getting NEON for VOLK to compile, isn't is the way to build GNURadio
 from source?  I remember I used VOLK file in GNURadio source files.

 Since you made it work, could you please tell me the exact details of
 right
 way you used? Thank you so much. I think most of instructions in GNURadio
 websites are painful.

 Thank you very much. I will be very grateful for any help from you.

 Shaun







 -- 
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Cross-compile-GNURadio-on-ARM-in-Odroid-XU3-tp54685p54690.html

 Sent from the GnuRadio mailing list archive at Nabble.com.

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

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

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

Re: [Discuss-gnuradio] Writing RSSI Values to a File Twice/Sec

[Philip Balister]

On 07/02/2015 11:07 AM, Varun Nambiar wrote:
 Hi all,
 
 
 I'm new to GNURadio and I'm trying to use a USRP E310 to capture GSM signals 
 from a cellphone and store the RSSI values in a text file. If you take a look 
 at my flow graph I've managed to capture the average strength across the 
 200kHz GSM band and I'm trying to filter out the unwanted signals using the 
 Probe Avg Mag^2 block.
 
 
 I'm having trouble writing to the file sink at a constant 2 samp/sec. Could 
 you please give me advice on how I should fix my flow graph?

What kind of trouble? Can you also post the grc file so I can try it
locally.

Also, which file system image are you using? The one from the card that
came with the unit, or release-2?

Philip


 
 
 Thank you,
 
 Varun
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

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

Re: [Discuss-gnuradio] Writing RSSI Values to a File Twice/Sec

[Philip Balister]

On 07/02/2015 11:25 AM, Varun Nambiar wrote:
 Hi Philip,
 
 At the moment of execution a file size of 32KB with just 0s is written to my 
 file and then it doesn't add anymore values after that. I am on release-2 and 
 I've attached my GRC file.

I dropped the throttle block and saw the output file get larger. Resend
the flowgraph to the list and maybe someone else has some ideas how to
make it better.

Philip


 
 Thank you,
 Varun
 
 
 From: Philip Balister phi...@balister.org
 Sent: Thursday, July 2, 2015 11:18 AM
 To: Varun Nambiar; discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Writing RSSI Values to a File Twice/Sec
 
 On 07/02/2015 11:07 AM, Varun Nambiar wrote:
 Hi all,


 I'm new to GNURadio and I'm trying to use a USRP E310 to capture GSM signals 
 from a cellphone and store the RSSI values in a text file. If you take a 
 look at my flow graph I've managed to capture the average strength across 
 the 200kHz GSM band and I'm trying to filter out the unwanted signals using 
 the Probe Avg Mag^2 block.


 I'm having trouble writing to the file sink at a constant 2 samp/sec. Could 
 you please give me advice on how I should fix my flow graph?
 
 What kind of trouble? Can you also post the grc file so I can try it
 locally.
 
 Also, which file system image are you using? The one from the card that
 came with the unit, or release-2?
 
 Philip
 
 


 Thank you,

 Varun



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.gnu.org_mailman_listinfo_discuss-2Dgnuradiod=AwIC-gc=1QsCMERiq7JOmEnKpsSyjgr=oML8w7v4Y02f11gsS3bWKQm=hC1yMZO9YJC94wCgIZWYH9bbke_ocPJKoWRVfAMsuMos=8BPBpMr_86l6B-6kzl20V_C-fjCtQ-eOYPqCNrrvwCEe=


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

Re: [Discuss-gnuradio] Embedded WG

[Philip Balister]

On 06/15/2015 10:38 PM, Nowlan, Sean wrote:
 For the next year,  I'd like to get more people actually using the 
 infrastructure
 
 we have. I'd like to get a list of gnuradio apps together and start 
 validating
 
 they run on various embedded platforms.
 
 
 
 I've been doing a little benchmarking of GR on various embedded platforms, 
 but I've been using different O/Ses on each (Ubuntu 14.04.2 LTS on ODROID XU3 
 and C1, Ubuntu 15.04 on RPi2, J Corgan's bootable USB stick on a Minnowboard, 
 and OE on E310). For uniformity, I agree that it would be nice to have an OE 
 way to do build across all these targets. I've also been working on tuning 
 compile flags for XU3. I'm planning to share some results with the community 
 in the next few weeks.

Yeah, there is quite a variety to keep with. Especially for the lower
speed platforms, having good cross toolchains is a huge win. I tire of
answering the internal compiler error question :)

Philip

 
 
 
 I'd also like some feedback on who would attend a WG call sometime in the
 
 next few weeks.
 
 
 
 I'm interested.
 
 

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

[Discuss-gnuradio] Embedded WG

[Philip Balister]

Recently I was asked how people can help with the embedded working
group. Currently, I a very happy with our support for Zynq based boards.
I've put together a list othings I think we can improve.

Embedded Working goals:

 1) Expand hardware support
- Wandboard
- r-pi2
- Jetson
- insert your favorite here

 2) More stuff in meta-sdr
- sdr shiny
- OOT modules

 3) Performance improvements
- Need to better understand bottlenecks

 4) Killer apps!
- Verify gnuradio examples

 5) Expand participation

The first couple of items involve OpenEmbedded work, finding BSP layers
for boards, testing them, working to get them creating easy to use
images, and writing recipes for more OOT modules.

For the next year,  I'd like to get more people actually using the
infrastructure we have. I'd like to get a list of gnuradio apps together
and start validating they run on various embedded platforms.

Even better, writing gnuradio applications designed to run well on
embedded systems.

I'd also like some feedback on who would attend a WG call sometime in
the next few weeks.

Philip

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

Re: [Discuss-gnuradio] Regular FM radio fine, POCSAG horrible

[Philip Balister]

On 06/02/2015 11:22 AM, West, Nathan wrote:
 I've heard a complaint about something similar on ARM before that was VOLK
 related. Can you set your volk_config to use the neon for
 volk_32f_x2_dot_prod_32f and report back?
 
 If the previous request is confusing just copy this file [0] to
 ~/.volk/volk_config.
 
 [0]
 https://raw.githubusercontent.com/balister/meta-sdr/f1ce8601482655695cb27b06aefbf9a620a27bd0/recipes-support/volk/files/ettus-e300/volk_config

That is the output of volk_profile run on an E310. You may get better
results running volk_profile on your hardware. Then making the change
Nathan suggests.

Philip

 
 I'm interested in results and can provide more detailed steps in a few
 hours if needed.
 
 -Nathan
 
 On Tue, Jun 2, 2015 at 10:29 AM, Stephan van Beerschoten 
 step...@vanbeerschoten.net wrote:
 
 Let me add that I don't know anything about the signal, other than that
 it's broadcast on 155.520MHz.

 On Tue, Jun 2, 2015 at 3:19 AM, Marcus Müller marcus.muel...@ettus.com
 wrote:

  Hi Stephan,

 I am sure GR can do that, but I can't ;-)

 I can't help but propose you change that ;) No, seriously,
 cross-compiling GNU Radio for an ARM sounds more complicated than doing
 non-coherent binary FSK demod, but then again, that might just be me :D.

 In fact, you're absolutely right: getting a solid signal quality before
 attempting decoding might be a good idea. However, most probably pagers
 don't need awesome SNR, so somewhat noisy might still be ok.

 so how do you get the samples into GNU Radio?
 I guess you use the gr-osmosdr source? which sampling rate? Where in your
 base band are your carriers?
 What does your flow graph look like?

 Generally: If you have a RF recording, [1] might just profit from one
 more entry, and we'd have something more tangible to talk about :)

 I'll outline the steps I'd do to try to achieve better signal:


1. Record a signal and test with that -- doing everything live makes
things complicated and hard to reproduce.
 2. Use a xlating FIR filter to move a single 12.5kHz channel to 0Hz,
so that either symbol is +- 4.5kHz
   1. this will require that you design a filter. Don't worry, that's
   relatively easy:
  1. run gr_filter_design
  2. select low pass, enter your source's sampling rate, set the
  end of the pass band to let's say 5kHz and the start of the stop 
 band to
  7.5kHz (If I understand wikipedia correctly, channel spacing is 
 12.5kHz,
  and symbol deviation is +-4.5kHz, so from the center of the lower 
 channel
  to the lower bit of the upper channel it's 12.5kHz - 4.5kHz = 
 8kHz).
   3. You'll notice that if you start with a high sampling rate,
  your filter gets ridiculously long. If that's the case, you might 
 want to
  reduce the sampling rate of your signal source, or add a stage of 
 half- or
  quarter bandwidth FIR decimation (with a decimation factor of 2 or 
 4,
  respectively)
   2. set the decimation of that xlating FIR to something reasonable,
   so that rate_in/decimation  12.5kHz/2, but not .
1. this way, you'll get just enough rate at the output.
   3. set the center frequency to the middle of your two symbol
   frequencies in the input spectrum
3. add visualization sinks here and there, and verify :)
4. add a real high-pass filter
   1. Your single-channel spectrum looks something like [1] with 0 Hz
   in the middle.  Since we've filtered away stuff above 5kHz, we'd now
   concern ourselves with filtering away everything below 4kHz.
   2. Same procedure as for the xlating fir, but use the reduced
   sampling rate and a 4 kHz high-pass with a 2kHz stop band or 
 something. The
   closer the stop band is to pass band, the longer your filter gets.
3. In principle, a 4-5 kHz real-tapped bandpass xlating fir would
   have done the same, but doing this step by step reduces error 
 probability.
5. repeat add visualizations :)
6. You should now have a clean signal with only two peaks in your
spectrum at +-4.5kHz; does your external decoder deal well with that?

 In principle, you're extremely close to having your own decoder by now.
 Non-coherent BFSK decoding would simply do the same as step 2, but with two
 filters, each centered on either symbol frequency, baudrate-wide passband,
 decimating to the baudrate, followed by a complex-to-magnituded-squared
 conversion each, then something like division of the 1-filter magsquared by
 the 0-filter magsquared, followed by a threshold decision (threshold=1).
 You'd then be getting a raw POCSAG bitstream :D
  Best regards,
 Marcus


 [1] from http://edge.rit.edu/edge/P09141/public/FSK.pdf ,
 Watkins-Johnson Company Tech-notes Vol. 7 No. 5 September/October 1980:
 FSK: Signals and Demodulation, p. 8 [image: FSK spectrum]
 http://edge.rit.edu/edge/P09141/public/FSK.pdf

 On 06/02/2015 12:04 AM, 

[Discuss-gnuradio] Meet GNU Radio developers at the Wireless@VT Symposium

[Philip Balister]

There will be a number of GNU Radio developers at the Wireless@VT
Symposium[1] next week. We are having a small reception at my house,
near the Inn at VT. We'll start gathering after 6PM on Tuesday, the
evening before the event starts.

We'll have some beer and food (likely pizza).

Drop me an email if you plan to attend so we know how much to purchase.
We'll try to leave directions at the Symposium hotel and I'd be glad to
send you directions.

This should be a good chance to talk to GNU Radio users and developers.

Philip

[1] https://wireless.vt.edu/symposium2015.html

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

Re: [Discuss-gnuradio] E310 shutdown issue

[Philip Balister]

On 05/08/2015 07:57 AM, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC wrote:
 My e310's (two that I've tested) are hanging at unmounting the mmcblk0p1 
 partition on shutdown, occasionally causing the filesystem to be corrupted. 
 Any ideas what is happening and how to get a clean shutdown?

How are you shutting them down?

Philip


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

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

Re: [Discuss-gnuradio] Bitbake GNU radio for Zynq

[Philip Balister]

On 05/05/2015 05:41 PM, Jeff Tu wrote:
 Hi Guys,
 
 Thanks for the help. I can build the kernel and run it on a Zedboard using 
 the dizzy branch exclusively. The additional step of using the 
 zynq-gnuradio-manifest repo to try to include the FIR example is what broke 
 things. That repo manifest replaces the meta-xilinx layer with an older one. 
 My plan was to try out the zynq-fir-filter-example, but I think I'll just use 
 it as a reference for now. Thanks!

I would be really nice to update the Zynq FIR ACP co-processor to work
with recent builds. Bonus point for integrating with Alfredo's work on
using GNU Radio buffers without the copy (and without magical
allocators). [1]

Philip

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Keystone2

 
 Jeff
 
 
 - Original Message -
 From: Murray Thomson murraythomson...@gmail.com
 To: Jeff Tu j...@skybox.com
 Cc: Philip Balister phi...@balister.org, GNURadio Discussion List 
 discuss-gnuradio@gnu.org
 Sent: Monday, May 4, 2015 1:25:13 PM
 Subject: Re: [Discuss-gnuradio] Bitbake GNU radio for Zynq
 
 Jeff,
 
 It looks like eglibc was at some point before dizzy renamed to glibc.
 
 daisy: poky/meta/recipes-core/eglibc/eglibc-package.inc
 dizzy: poky/meta/recipes-core/glibc/glibc-package.inc
 
 Recipes from dizzy shouldn't depend on eglibc. The xilinx layer seems to
 have change this
 https://lists.yoctoproject.org/pipermail/meta-xilinx/2014-September/000751.html
 
 If you are sure that all your layers are using dizzy and still asks for
 eglibc, you may get better luck with another branch.
 It would be interesting to see if you can build a minimal console image. If
 you can, take a look at the first part of the log printed in the console,
 it will tell you the branch that the layers are using.
 
 Regards,
 Murray
 
 
 
 
 2015-05-04 17:17 GMT+01:00 Jeff Tu j...@skybox.com:
 
 Hi Philip and Murray,

 Thanks for your help. I mentioned that I was actually working off the
 dizzy branch. I also went through all the branches available for the
 meta-xilinx repo and could not find the file:

 ERROR: ParseError at
 /home/jeff/Desktop/gnu/oe-repo/oe-core/../meta-xilinx/recipes-core/meta/
 external-xilinx-toolchain.bb:1:
 Could not include required file recipes-core/eglibc/eglibc-package.inc

 Also as a note I'm running on Ubuntu 12.04.

 Thanks again!
 Jeff


 - Original Message -
 From: Philip Balister phi...@balister.org
 To: Murray Thomson murraythomson...@gmail.com, Jeff Tu 
 j...@skybox.com
 Cc: GNURadio Discussion List discuss-gnuradio@gnu.org
 Sent: Monday, May 4, 2015 6:59:51 AM
 Subject: Re: [Discuss-gnuradio] Bitbake GNU radio for Zynq

 On 05/04/2015 06:11 AM, Murray Thomson wrote:
 Hi Jeff,

 I think is worth checking that you are using the same branch (dizzy) in
 all
 the beta layers that you have. Including openembedded, yocto, meta-sdr...
 The reason why you were missing meta-python could be that your
 openembedded
 layer is newer than the meta-sdr used to create the bblayers.conf file. I
 would suggest that you try checking out the branch that you want instead
 of
 the latest stable one.

 Use:



 $ git clone git://github.com/balister/oe-gnuradio-manifest.git -b dizzy

 I need to update the manifest and delete stable :)

 Philip


 Cheers,
 Murray


 2015-05-04 3:20 GMT+01:00 Jeff Tu j...@skybox.com:

 Hi,

 I'm a trying to compile GNU radio for Zynq using the example described
 here:

 https://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq

 The instructions do have an out of date warning, and I'm just trying to
 figure out what things to update. From another list posting, there are
 instructions to checkout the dizzy branch instead of stable in the
 following line:

 $ git clone git://github.com/balister/oe-gnuradio-manifest.git -b
 stable

 When I reach the bitbake step:
 $ bitbake gnuradio-dev-image

 It first fails due a missing meta-python layer. That's easily solved by
 modifying the bblayers.conf file to include meta-python. After that, I
 get
 the following error:

 ERROR: ParseError at
 /home/jeff/Desktop/gnu/oe-repo/oe-core/../meta-xilinx/recipes-core/meta/
 external-xilinx-toolchain.bb:1: Could not include required file
 recipes-core/eglibc/eglibc-package.inc

 I cannot find any eglibc-package.inc in the file system. Any ideas?


 Any help would be greatly appreciated! Sorry, I'm a complete GNU radio
 beginner!
 Thanks,
 Jeff

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




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


 
 

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

Re: [Discuss-gnuradio] Bitbake GNU radio for Zynq

[Philip Balister]

On 05/04/2015 06:11 AM, Murray Thomson wrote:
 Hi Jeff,
 
 I think is worth checking that you are using the same branch (dizzy) in all
 the beta layers that you have. Including openembedded, yocto, meta-sdr...
 The reason why you were missing meta-python could be that your openembedded
 layer is newer than the meta-sdr used to create the bblayers.conf file. I
 would suggest that you try checking out the branch that you want instead of
 the latest stable one.

Use:



$ git clone git://github.com/balister/oe-gnuradio-manifest.git -b dizzy

I need to update the manifest and delete stable :)

Philip

 
 Cheers,
 Murray
 
 
 2015-05-04 3:20 GMT+01:00 Jeff Tu j...@skybox.com:
 
 Hi,

 I'm a trying to compile GNU radio for Zynq using the example described
 here:

 https://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq

 The instructions do have an out of date warning, and I'm just trying to
 figure out what things to update. From another list posting, there are
 instructions to checkout the dizzy branch instead of stable in the
 following line:

 $ git clone git://github.com/balister/oe-gnuradio-manifest.git -b stable

 When I reach the bitbake step:
 $ bitbake gnuradio-dev-image

 It first fails due a missing meta-python layer. That's easily solved by
 modifying the bblayers.conf file to include meta-python. After that, I get
 the following error:

 ERROR: ParseError at
 /home/jeff/Desktop/gnu/oe-repo/oe-core/../meta-xilinx/recipes-core/meta/
 external-xilinx-toolchain.bb:1: Could not include required file
 recipes-core/eglibc/eglibc-package.inc

 I cannot find any eglibc-package.inc in the file system. Any ideas?


 Any help would be greatly appreciated! Sorry, I'm a complete GNU radio
 beginner!
 Thanks,
 Jeff

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

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

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

Re: [Discuss-gnuradio] Bitbaking GnuRadio with meta-sdr master issues

[Philip Balister]

On 04/21/2015 09:43 AM, Murray Thomson wrote:
 On 20 April 2015 at 15:13, Philip Balister phi...@balister.org wrote:
 


 On 04/19/2015 11:07 AM, Murray Thomson wrote:
 Hello,

 I have built the gnuradio-dev-image for an arm machine and I wanted to
 share a couple of small issues that I found in the process.

 - The meta-sdr/conf/bblayers.conf.sample doesn't include all the layers
 needed. This is correctly warned in the README file of the layer. I've
 attached the file that worked for me in case someone finds it useful.

 You layer.conf file has loads of layers the dev image shouldn't need? Do
 you know exactly which ones are missing? I'm setting the default for
 meta-sdr so you can build demo image out of the box. The demo + video
 layer recipe lists some additional layers you will need.

 
 I didn't realize that the dependencies that I had missing were necessary
 for my target machine, but not required for meta-sdr, sorry. I've checked
 the dependencies with bitbake -g gnuradio-demo-image and the ones in
 bblayers.conf.sample are correct. The only thing I would suggest is to
 replace meta-oe for meta-openembedded as recommended in their github
 https://github.com/openembedded.

Thanks for checking the default is OK.

This should prevent trouble when the short named repos go away:

https://github.com/balister/oe-gnuradio-manifest/commit/967909b59de87ad62462decac626d9637437

I left the directories they get checked out into the same for now. I
suppose I'll change the names at some point, maybe when I do the fido
branch.

Philip

Philip

 
 
 Philip


 - A couple of the layers include recipe.bbappend files for recipes that
 have been updated recently. I solved this ignoring them with BBMASK as
 you
 can see in the bblayers.conf file.

 - valgrind recipe failed. This seem to be a problem with the Yocto master
 branch so I deleted it from the recipes and I built without it.

 - volk failed to compile for qemuarm machine. I couldn't work around this
 one. I've attached the log file. Some of the recipes, including
 gnuradio_git depend on it so I don't think I'll be able to ignore it.

 The only real issue is the last one. It would be great to be able to
 compile for qemuarm. Could anyone give me a pointer to fix this? My
 machine
 runs Ubuntu 12.04 32 bit and the master branch for all the BSPs.

 Thanks,
 Murray



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


 

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

Re: [Discuss-gnuradio] Bitbaking GnuRadio with meta-sdr master issues

[Philip Balister]

On 04/19/2015 11:07 AM, Murray Thomson wrote:
 Hello,
 
 I have built the gnuradio-dev-image for an arm machine and I wanted to
 share a couple of small issues that I found in the process.
 
 - The meta-sdr/conf/bblayers.conf.sample doesn't include all the layers
 needed. This is correctly warned in the README file of the layer. I've
 attached the file that worked for me in case someone finds it useful.

You layer.conf file has loads of layers the dev image shouldn't need? Do
you know exactly which ones are missing? I'm setting the default for
meta-sdr so you can build demo image out of the box. The demo + video
layer recipe lists some additional layers you will need.

Philip

 
 - A couple of the layers include recipe.bbappend files for recipes that
 have been updated recently. I solved this ignoring them with BBMASK as you
 can see in the bblayers.conf file.
 
 - valgrind recipe failed. This seem to be a problem with the Yocto master
 branch so I deleted it from the recipes and I built without it.
 
 - volk failed to compile for qemuarm machine. I couldn't work around this
 one. I've attached the log file. Some of the recipes, including
 gnuradio_git depend on it so I don't think I'll be able to ignore it.
 
 The only real issue is the last one. It would be great to be able to
 compile for qemuarm. Could anyone give me a pointer to fix this? My machine
 runs Ubuntu 12.04 32 bit and the master branch for all the BSPs.
 
 Thanks,
 Murray
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

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

Re: [Discuss-gnuradio] Bitbaking GnuRadio with meta-sdr master issues

[Philip Balister]

On 04/19/2015 11:07 AM, Murray Thomson wrote:
 Hello,
 
 I have built the gnuradio-dev-image for an arm machine and I wanted to
 share a couple of small issues that I found in the process.
 
 - The meta-sdr/conf/bblayers.conf.sample doesn't include all the layers
 needed. This is correctly warned in the README file of the layer. I've
 attached the file that worked for me in case someone finds it useful.
 

I'll double check this.

 - A couple of the layers include recipe.bbappend files for recipes that
 have been updated recently. I solved this ignoring them with BBMASK as you
 can see in the bblayers.conf file.
 
 - valgrind recipe failed. This seem to be a problem with the Yocto master
 branch so I deleted it from the recipes and I built without it.
 

Master will be a bit messy for a while. Right now a lot of post release
updates are going in, so I expect things to be unstable for a bit.

 - volk failed to compile for qemuarm machine. I couldn't work around this
 one. I've attached the log file. Some of the recipes, including
 gnuradio_git depend on it so I don't think I'll be able to ignore it.
 

Looks like that is a machine without neon support. I suspect volk needs
to be a little more careful working out if neon is available.

 The only real issue is the last one. It would be great to be able to
 compile for qemuarm. Could anyone give me a pointer to fix this? My machine
 runs Ubuntu 12.04 32 bit and the master branch for all the BSPs.
 
 Thanks,
 Murray
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

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