[Discuss-gnuradio] merging gnuradio repos

[Peter]

Hello,

I have recently updated both the uhd and gnuradio from an older version.
I cannot run my python files in this newer version. I see some of the file
locations in gnuradio have changed.
And there are multiple such error instances when I run my python files
e.g., ofdm_utils not found, psk not found and so on.
Is there anything in general that I have to change in my python files to
get rid of these errors.

Secondly I have another query. See the steps below and kindly answer

1. mkdir myMainFolder
2. cd myMainFolder
3. git clone 
At this stage I get a gnuradio folder in myMainFolder. If I want to have a
code from another gnuradio repo such as  and merge both
 and  at which level should I do this ?
4a. Is it cd /myMainFolder and do a git clone  or
4b. Is it cd /myMainFolder/gnuradio and then do a git clone 


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

Re: [Discuss-gnuradio] Tune UHD - as fast as possible

[Marius]

Hi!

On 10 February 2012 18:12, Marcus D. Leech  wrote:
> Ive used XMLRPC for the same thing and you don't have to worry about 
> unpacking integers into floating point etc

Ah, the XMLRPC block automatically adds callback functions for the
variables. That's a great startpoint. Thanks a lot. Now I finally know
why someone would need an XMLRPC in DSP ;)

> On Feb 10, 2012, at 10:49 AM, Ed Criscuolo  
> wrote:
>> Use an external program to send a UDP packet to the port number
>> of the UDP source block.  The packet should contain a single
>> integer representing the frequency.  Pay attention to byte-order.
>>
>> I've used this setup to apply doppler correction from an external
>> program when receiving telemetry from a spacecraft.  We were only
>> sending packets about once per second, so I don't know how fast
>> this setup will go, but it's worth pursuing.
>>
>> @(^.^)@  Ed
>>

I hope it doesn't add any latency to the equation like: RPC command +
UHD command + FPGA reaction + RF frontend. I'm not even sure if using
the C++ API would be any different. So my Monday morning experiment
now is set ;)

Best,
Marius

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

[Discuss-gnuradio] A portable Build of GNU Radio 3.4 to test

[Marius]

Hi!

I have looked into the GNU Radio installation process a lot. Since I
see us facing dependency hell, I created a portable build (for any
Linux 2.6, x64 system). This is not distribution specific.

It's based on a Stanford research project named CDE (Code, Data, and
Environment). It works as a cross-Linux way to distribute software by
implementing a lightweight virtualization (ptrace redirect). There's a
nice short video at http://www.stanford.edu/~pgbovine/cde.html

In order to test this I uploaded a CDE build of GNU Radio 3.4.0, GCC
x86_64 build, UHD_003.002.002-e033fc3 (host utilities). I ran some
FFTs, Filters and Demodulation Blocks. Works fine here.

Download: http://crazylazy.info/cde/gnuradio_cde.7z
40876ecb5e9180cbc08e361139a8c551  gnuradio_cde.7z

If you find any files missing, please mention it. Since this is new to
me I have no experience whether this works for real with other
people's system , different distributions etc. You can easily add your
libs by running the cde binary and let it output into the unpacked
folder. The only dependency here is Linux 2.6 and an x86_64
installation.

Best,
Marius

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

Re: [Discuss-gnuradio] Tune UHD - as fast as possible

[Marcus D. Leech]

On 11/02/12 05:50 AM, Marius wrote:
>
> I hope it doesn't add any latency to the equation like: RPC command +
> UHD command + FPGA reaction + RF frontend. I'm not even sure if using
> the C++ API would be any different. So my Monday morning experiment
> now is set ;)
>
> Best,
> Marius
>
>
>   
Well, yes, it will add latency. Not a lot, but *some*.   The hardware
generally takes about 1ms
  to tune and lock.

If you want absolute minimum latency without doing an FPGA-based
implementation, then stick
  entirely with the C++ API. GRC produces Python, and while the blocks
themselves are mostly
  written in C++, things like parameter changes to blocks (including
source/sinks) have to
  "percolate" through Python first, and it's an interpreted language.




-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

[Discuss-gnuradio] Fwd: Homebrew Your Own Supercomputer

[Justin Kelly]

For the next design cycle you guys might want to look at what these guys
have to offer...


I read about GreenArrays INC in the latest issue of QST Today, on page 97
in Vol 96 No 3

The company is offering for sale the GA144 processor with 144 cores! for
the princely sum of $20.00

power consumption is speced at less then a watt, and they claim it can do
90 billion instructions a second.
 

http://www.greenarraychips.com/home/products/index.html

The minimum order is one 10-pack (ten chips)



-- 
"It's amazing how productive doing nothing can be..."   - - -Kevin Flynn

Every revolutionary idea seems to evoke three stages of reaction. They may
be summed up by the phrases: 1- It's completely impossible. 2- It's
possible, but it's not worth doing. 3- I said it was a good idea all along.

Any sufficiently advanced technology is indistinguishable from magic. - - -
Arthur C. Clarke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] A helper software to tune your antenna

[Patrik Tast]

HI All,

For those interested:

A windows software is available for tuning your parabolic- or offset dish feed 
from 1 GHz to ->
It creates a NEC (Numerical Electromagnetics Code) model of your antenna so you 
can verify it (or get started) 

The (win + src) software is available from 
http://www.poes-weather.com/~patrik/8.2GHz/sw/
The latest, February release is called antenna-1st-aid-2012-02.

NOTICE: It is called *Antenna-1st-aid*. Tons of real-world tests needed, but it 
will give you a clue...

A youtube 4NEC2 model simulation at 8.2 GHz when moving a horn from the 
aperture down
http://www.youtube.com/watch?v=xYfb_M3vKsc

This software should be used only as a guide. Tweak it using NEC and then in 
real world.
Next version will be (Qt) at github.

Have fun,
Patrik___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OSX UHD runtime troubles

[Daniel O'Connor]

Hi,
I'm trying to build and run GNURadio on OSX Lion (with MacPorts) but I am 
having trouble with UHD.

I've built and install GNURadio (from git) however when I run anything the 
Python interpreter crashes like so..
In [1]: import gnuradio.uhd
Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 
2335.15.00); Boost_104800; UHD_003.004.000-122b947

Fatal Python error: Interpreter not initialized (version mismatch?)

Since I initially got UHD as a binary I uninstalled it then built it from the 
sources but I get the same problem.

Running 'ccmake' shows the Python path as /opt/local/bin as I expect.

The stack trace and binary image list look like so..
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff8bd5982a __kill + 10
1   libsystem_c.dylib   0x7fff892b6a9c abort + 177
2   org.python.python   0x0001035b196e Py_FatalError + 49
3   org.python.python   0x0001035af46b Py_InitModule4_64 + 
74
4   _uhd_swig.so0x000103472b8f init_uhd_swig + 543
5   org.python.python   0x000102fce1aa 
_PyImport_LoadDynamicModule + 170
6   org.python.python   0x000102fcaae5 imp_load_module + 341
7   org.python.python   0x000102fb4a7b PyEval_EvalFrameEx + 
18011
8   org.python.python   0x000102fb7e13 fast_function + 179
9   org.python.python   0x000102fb4b2d PyEval_EvalFrameEx + 
18189
10  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
11  org.python.python   0x000102fb7d56 PyEval_EvalCode + 54
12  org.python.python   0x000102fcb123 
PyImport_ExecCodeModuleEx + 243
13  org.python.python   0x000102fcb796 load_source_module + 
1462
14  org.python.python   0x000102fcc763 import_submodule + 
467
15  org.python.python   0x000102fcc97b load_next + 251
16  org.python.python   0x000102fcd7d0 
PyImport_ImportModuleLevel + 1184
17  org.python.python   0x000102faadf4 builtin___import__ + 
132
18  org.python.python   0x000102f1cae1 PyObject_Call + 97
19  org.python.python   0x000102faf824 
PyEval_CallObjectWithKeywords + 180
20  org.python.python   0x000102fb6746 PyEval_EvalFrameEx + 
25382
21  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
22  org.python.python   0x000102fb7e88 fast_function + 296
23  org.python.python   0x000102fb4b2d PyEval_EvalFrameEx + 
18189
24  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
25  org.python.python   0x000102fb7d56 PyEval_EvalCode + 54
26  org.python.python   0x000102fcb123 
PyImport_ExecCodeModuleEx + 243
27  org.python.python   0x000102fcb796 load_source_module + 
1462
28  org.python.python   0x000102fcc155 load_package + 357
29  org.python.python   0x000102fcc763 import_submodule + 
467
30  org.python.python   0x000102fcc97b load_next + 251
31  org.python.python   0x000102fcd815 
PyImport_ImportModuleLevel + 1253
32  org.python.python   0x000102faadf4 builtin___import__ + 
132
33  org.python.python   0x000102f1cae1 PyObject_Call + 97
34  org.python.python   0x000102faf824 
PyEval_CallObjectWithKeywords + 180
35  org.python.python   0x000102fb6746 PyEval_EvalFrameEx + 
25382
36  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
37  org.python.python   0x000102fb7d56 PyEval_EvalCode + 54
38  org.python.python   0x000102fd7ca2 
PyRun_InteractiveOneFlags + 578
39  org.python.python   0x000102fd7dfe 
PyRun_InteractiveLoopFlags + 222
40  org.python.python   0x000102fd7ea7 PyRun_AnyFileExFlags 
+ 119
41  org.python.python   0x000102fea919 Py_Main + 2969
42  org.python.python   0x000102f0af14 0x102f0a000 + 3860

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x  rbx: 0x7fff62b06430  rcx: 0x7fff62b06418  
rdx: 0x
  rdi: 0x6cfe  rsi: 0x0006  rbp: 0x7fff62b06440  
rsp: 0x7fff62b06418
   r8: 0x03f5   r9: 0x7fff62b06438  r10: 0x7fff8bd5ae62  
r11: 0xff80002d8220
  r12: 0x0001034d2212  r13: 0x  r14: 0x  
r15: 0x0001034e9420
  rip: 0x7fff8bd5982a  rfl: 0x0202  cr2: 0x0001035ef464
Logical CPU: 0

Binary Images:
   0x102f0a000 -0x102f0aff7 +org.python.python (2.7.2 - 2.7.2) 
 
/opt/l

Re: [Discuss-gnuradio] Three different USRP2 nodes are transmitting with almost exactly 1 MHz frequency offset

[Nazmul Islam]

Hello Ben,

Shantharam, my colleague, installed the latest UHD image. Now I don't see
the 1 MHz frequency offset any more. The benchmark_rx program is also
receiving packets correctly from the benchmark_tx code.

Thanks a lot for your help. We really appreciate your effort.

Nazmul

On Thu, Feb 9, 2012 at 12:44 PM, Ben Hilburn  wrote:

> Nazmul -
>
> Your version of UHD is from November 22nd.  Will you try updating your UHD
> install?
>
> I'm not sure how you installed, or how familiar you are with git / Linux
>  - here is a quick command list, assuming you used Git to checkout the code
> to begin with, and it is in a directory called uhd.git/
>
> $ cd uhd.git
> $ git checkout master
> $ git remote update; git pull
> $ rm -rf build
> $ mkdir build; cd build
> $ cmake ../ && make
>
> Let us know how it goes!
>
> Cheers,
> Ben
>
> On Wed, Feb 8, 2012 at 8:52 PM, Nazmul Islam 
> wrote:
>
>> Thanks for the reply, Jason. The uhd_usrp_probe --version command gave
>> the following result:
>>
>> linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.004.000-71810ad
>>
>> 003.004.000-71810ad
>>
>> Do I have to download the latest UHD image? The image that I am using
>> right now was downloaded by one of my colleagues and I think that he did it
>> recently.
>>
>> Also, I tried running the benchmark_tx and benchmark_rx codes with a 1
>> MHz frequency offset input, i.e., I gave the following commands:
>>
>> ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -a "addr = 192.168.10.2"
>>
>> ./benchmark_tx.py -f 2.401G -r 1M -m gmsk -a "addr = 192.168.10.2"
>>
>> Since the uhd_fft.py and the my lab spectrum analyzer show a 1 MHz
>> frequency offset, I assumed that the above commands would work.
>> Unfortunately, this did not help either!
>>
>> Suggestions will be very appreciated.
>>
>> Thanks,
>>
>> Nazmul
>>
>>
>>
>>
>> On Wed, Feb 8, 2012 at 7:37 PM, Jason Abele  wrote:
>>
>>> On Wed, Feb 08, 2012 at 06:39:24PM -0500, Nazmul Islam wrote:
>>> > Hello,
>>> >
>>> > I am running the benchmark_tx.py codes and looking at the spectrum of
>>> the
>>> > signals using uhd_fft.py. I am using the latest image of GNU radio
>>> > (GNUradio 3.5) and I have XCVR2450 daughterboards. I ran the
>>> > benchmark_tx.py code in three transmitter nodes and surprisingly, all
>>> of
>>> > them are transmitting with 1 MHz frequency offset! I have attached two
>>> > screenshots with the email (I hope that they go through). I give the
>>> > following input parameters to run the benchmark_tx code.
>>> >
>>> > ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -M 10 -a "addr = 192.168.10.2"
>>> >
>>> > Both uhd_fft.py and the spectrum analyzer of my laboratory show that
>>> the
>>> > received signal is centered at 2.401 GHz. I varied the frequency to
>>> 2.45
>>> > GHz, 2.41 GHz, but this 1 MHz frequency shift persists.
>>> >
>>> > When I run the benchmark_rx.py code at the receiver nodes, they don't
>>> > receive/detect any packets (due to the frequency offset, I guess). I
>>> even
>>> > tried to run the transmitter at 2.4 GHz and the receiver at 2.401 GHz.
>>> > However, that did not help either!
>>> >
>>> > I will try to modify the control loop gain parameters using Tom's blogs
>>> > suggestions and see if that helps. However, I am really surprised to
>>> see
>>> > how all three different transmitter nodes can transmit with almost
>>> exactly
>>> > 1 MHz frequency offset. Any suggestion will be appreciated.
>>> >
>>>
>>> Can you tell us which version of UHD you are using?
>>> (uhd_usrp_probe --version)
>>>
>>> We have heard reports of such an issue and my best guess is that it was
>>> related to an accidental swap of I and Q in the XCVR2450 transmitter
>>> code.  This went in after the 3.3.2 release and is fixed on latest UHD
>>> master since 837437c65ce36d418cceb3df5b093f9497b3af5f
>>>
>>> Jason
>>>
>>
>>
>>
>> --
>> Muhammad Nazmul Islam
>>
>> Graduate Student
>> Electrical & Computer Engineering
>> Wireless Information & Networking Laboratory
>> Rutgers, USA.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Three different USRP2 nodes are transmitting with almost exactly 1 MHz frequency offset

[shantharam balasubramanian]

Hi Ben,

I am happy to hear from Nazmul that the image works.



Thanks a lot for your help.


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

Re: [Discuss-gnuradio] OSX UHD runtime troubles

[Peter Jensen]

I had similar symptoms with my OSX Lion machine and macports-built 
dependencies. In my case, I was using the macports Python 2.6, but 
pmt_swig.so was linked against the OSX-provided Python 2.7 library, 
unlike everything else which was properly linked against the /opt/local 
macports python 2.6.


The cmake command line that got it working for me was:
cmake .. 
-DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib 
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6


In that case I'm not specifying the python executable because the proper 
one was first in the path. I don't know if this is exactly your problem, 
but it's definitely worth thinking through the library deps to make sure 
you are not mixing python installations up.


In your case I am suspicious of the 
"/System/Library/Frameworks/Python.framework/Versions/2.7/Python" 
dependency when everything else is pointing to /opt/local.


-Peter

On 02/11/2012 06:12 PM, Daniel O'Connor wrote:

Hi,
I'm trying to build and run GNURadio on OSX Lion (with MacPorts) but I am 
having trouble with UHD.

I've built and install GNURadio (from git) however when I run anything the 
Python interpreter crashes like so..
In [1]: import gnuradio.uhd
Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 
2335.15.00); Boost_104800; UHD_003.004.000-122b947

Fatal Python error: Interpreter not initialized (version mismatch?)

Since I initially got UHD as a binary I uninstalled it then built it from the 
sources but I get the same problem.

Running 'ccmake' shows the Python path as /opt/local/bin as I expect.

The stack trace and binary image list look like so..
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff8bd5982a __kill + 10
1   libsystem_c.dylib   0x7fff892b6a9c abort + 177
2   org.python.python   0x0001035b196e Py_FatalError + 49
3   org.python.python   0x0001035af46b Py_InitModule4_64 + 
74
4   _uhd_swig.so0x000103472b8f init_uhd_swig + 543
5   org.python.python   0x000102fce1aa 
_PyImport_LoadDynamicModule + 170
6   org.python.python   0x000102fcaae5 imp_load_module + 341
7   org.python.python   0x000102fb4a7b PyEval_EvalFrameEx + 
18011
8   org.python.python   0x000102fb7e13 fast_function + 179
9   org.python.python   0x000102fb4b2d PyEval_EvalFrameEx + 
18189
10  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
11  org.python.python   0x000102fb7d56 PyEval_EvalCode + 54
12  org.python.python   0x000102fcb123 
PyImport_ExecCodeModuleEx + 243
13  org.python.python   0x000102fcb796 load_source_module + 
1462
14  org.python.python   0x000102fcc763 import_submodule + 
467
15  org.python.python   0x000102fcc97b load_next + 251
16  org.python.python   0x000102fcd7d0 
PyImport_ImportModuleLevel + 1184
17  org.python.python   0x000102faadf4 builtin___import__ + 
132
18  org.python.python   0x000102f1cae1 PyObject_Call + 97
19  org.python.python   0x000102faf824 
PyEval_CallObjectWithKeywords + 180
20  org.python.python   0x000102fb6746 PyEval_EvalFrameEx + 
25382
21  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
22  org.python.python   0x000102fb7e88 fast_function + 296
23  org.python.python   0x000102fb4b2d PyEval_EvalFrameEx + 
18189
24  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
25  org.python.python   0x000102fb7d56 PyEval_EvalCode + 54
26  org.python.python   0x000102fcb123 
PyImport_ExecCodeModuleEx + 243
27  org.python.python   0x000102fcb796 load_source_module + 
1462
28  org.python.python   0x000102fcc155 load_package + 357
29  org.python.python   0x000102fcc763 import_submodule + 
467
30  org.python.python   0x000102fcc97b load_next + 251
31  org.python.python   0x000102fcd815 
PyImport_ImportModuleLevel + 1253
32  org.python.python   0x000102faadf4 builtin___import__ + 
132
33  org.python.python   0x000102f1cae1 PyObject_Call + 97
34  org.python.python   0x000102faf824 
PyEval_CallObjectWithKeywords + 180
35  org.python.python   0x000102fb6746 PyEval_EvalFrameEx + 
25382
36  org.python.python   0x000102fb7cd7 PyEval_EvalCodeEx + 
2103
37  org.python.python   0x000102fb7d56 PyEval_EvalCode + 54

Re: [Discuss-gnuradio] OSX UHD runtime troubles

[Daniel O'Connor]

On 12/02/2012, at 10:48, Peter Jensen wrote:
> I had similar symptoms with my OSX Lion machine and macports-built 
> dependencies. In my case, I was using the macports Python 2.6, but 
> pmt_swig.so was linked against the OSX-provided Python 2.7 library, unlike 
> everything else which was properly linked against the /opt/local macports 
> python 2.6.
> 
> The cmake command line that got it working for me was:
> cmake .. 
> -DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib
>  
> -DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6
> 
> In that case I'm not specifying the python executable because the proper one 
> was first in the path. I don't know if this is exactly your problem, but it's 
> definitely worth thinking through the library deps to make sure you are not 
> mixing python installations up.
> 
> In your case I am suspicious of the 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Python" dependency 
> when everything else is pointing to /opt/local.

Ah that's a good point.. I had assumed that MacPorts installed that, however I 
see that it installs elsewhere.

I re-cmake'd with..
cmake .. 
-DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib
 
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7

and now it works, thanks!

I can't actually test it with hardware yet but it's progress :)

> -Peter
> 
> On 02/11/2012 06:12 PM, Daniel O'Connor wrote:
>> Hi,
>> I'm trying to build and run GNURadio on OSX Lion (with MacPorts) but I am 
>> having trouble with UHD.
>> 
>> I've built and install GNURadio (from git) however when I run anything the 
>> Python interpreter crashes like so..
>> In [1]: import gnuradio.uhd
>> Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 
>> 2335.15.00); Boost_104800; UHD_003.004.000-122b947
>> 
>> Fatal Python error: Interpreter not initialized (version mismatch?)
>> 
>> Since I initially got UHD as a binary I uninstalled it then built it from 
>> the sources but I get the same problem.
>> 
>> Running 'ccmake' shows the Python path as /opt/local/bin as I expect.
>> 
>> The stack trace and binary image list look like so..
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   libsystem_kernel.dylib   0x7fff8bd5982a __kill + 10
>> 1   libsystem_c.dylib0x7fff892b6a9c abort + 177
>> 2   org.python.python0x0001035b196e Py_FatalError + 49
>> 3   org.python.python0x0001035af46b Py_InitModule4_64 + 
>> 74
>> 4   _uhd_swig.so 0x000103472b8f init_uhd_swig + 543
>> 5   org.python.python0x000102fce1aa 
>> _PyImport_LoadDynamicModule + 170
>> 6   org.python.python0x000102fcaae5 imp_load_module + 341
>> 7   org.python.python0x000102fb4a7b PyEval_EvalFrameEx + 
>> 18011
>> 8   org.python.python0x000102fb7e13 fast_function + 179
>> 9   org.python.python0x000102fb4b2d PyEval_EvalFrameEx + 
>> 18189
>> 10  org.python.python0x000102fb7cd7 PyEval_EvalCodeEx + 
>> 2103
>> 11  org.python.python0x000102fb7d56 PyEval_EvalCode + 54
>> 12  org.python.python0x000102fcb123 
>> PyImport_ExecCodeModuleEx + 243
>> 13  org.python.python0x000102fcb796 load_source_module + 
>> 1462
>> 14  org.python.python0x000102fcc763 import_submodule + 
>> 467
>> 15  org.python.python0x000102fcc97b load_next + 251
>> 16  org.python.python0x000102fcd7d0 
>> PyImport_ImportModuleLevel + 1184
>> 17  org.python.python0x000102faadf4 builtin___import__ + 
>> 132
>> 18  org.python.python0x000102f1cae1 PyObject_Call + 97
>> 19  org.python.python0x000102faf824 
>> PyEval_CallObjectWithKeywords + 180
>> 20  org.python.python0x000102fb6746 PyEval_EvalFrameEx + 
>> 25382
>> 21  org.python.python0x000102fb7cd7 PyEval_EvalCodeEx + 
>> 2103
>> 22  org.python.python0x000102fb7e88 fast_function + 296
>> 23  org.python.python0x000102fb4b2d PyEval_EvalFrameEx + 
>> 18189
>> 24  org.python.python0x000102fb7cd7 PyEval_EvalCodeEx + 
>> 2103
>> 25  org.python.python0x000102fb7d56 PyEval_EvalCode + 54
>> 26  org.python.python0x000102fcb123 
>> PyImport_ExecCodeModuleEx + 243
>> 27  org.python.python0x000102fcb796 load_source_module + 
>> 1462
>> 28  org.python.python0x000102fcc155 load_package + 357
>> 29  org.python.python0x000102fcc763 import_submodule + 
>> 467
>> 30  org.python.python