Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Vipin Sharma]

uhd-devel did the trick. No more crashes. Thanks a bunch!

Vipin

On Fri, Feb 2, 2018 at 11:18 AM, Michael Dickens 
wrote:

> Hi Vipin - OK; interesting. Can you try the following:
> {{{
> sudo port -f deactivate uhd
> sudo port install uhd-devel
> }}}
> then if those work, try running "uhd_fft" again & hopefully it will work.
> If not, send me the crash log off-list & we'll try something else. - MLD
>
> On Fri, Feb 2, 2018, at 1:23 PM, Vipin Sharma wrote:
>
> Actually, the install works fine but I am running into segmentation
> violation while running top_block.py through GRC GUI or uhd_fft on command
> line. Somewhere I am guessing Python versions are getting messed up. Here
> is the crash log after running 'uhd_fft -f 868M -s 10M'; how do I figure
> out what is causing the crash?
>
> Process:   Python [98722]
> Path:  /opt/local/Library/Frameworks/Python.framework/
> Versions/2.7/Resources/Python.app/Contents/MacOS/Python
> Identifier:org.python.python
> Version:   2.7.14 (2.7.14)
> Code Type: X86-64 (Native)
> Parent Process:bash [93492]
> Responsible:   Python [98722]
> User ID:   503
>
> Date/Time: 2018-02-02 10:19:04.736 -0800
> OS Version:Mac OS X 10.12.6 (16G1114)
> Report Version:12
> Anonymous UUID:120FE2C9-C399-E258-2FCC-CB15EFBA9026
>
> Sleep/Wake UUID:   F31F40DE-3B36-4430-A542-C83035144872
>
> Time Awake Since Boot: 27 seconds
> Time Since Wake:   2000 seconds
>
> System Integrity Protection: enabled
>
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x0037312e
> Exception Note:EXC_CORPSE_NOTIFY
>
> Termination Signal:Segmentation fault: 11
> Termination Reason:Namespace SIGNAL, Code 0xb
> Terminating Process:   exc handler [0]
>
> VM Regions Near 0x37312e:
> __LINKEDIT 0001266f3000-0001266ff000 [   48K]
> r--/rwx SM=COW  /System/Library/Extensions/IOUSBFamily.kext/Contents/
> PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib
> -->
> STACK GUARD7c905000-7c906000 [4K]
> ---/rwx SM=NUL  stack guard for thread 1
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libgnuradio-blocks.3.7.11.dylib 0x0001188b7f36
> boost::asio::detail::task_io_service::init_task() + 134
> 1   libgnuradio-blocks.3.7.11.dylib 0x0001188a4367
> boost::asio::io_service::service* boost::asio::detail::service_
> registry::create >(boost::asio::io_service&) + 105
> 2   libuhd.003.dylib   0x000119442167
> boost::asio::detail::service_registry::do_use_service(
> boost::asio::io_service::service::key const&, 
> boost::asio::io_service::service*
> (*)(boost::asio::io_service&)) + 127
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IFFT block output incorrect?

[Weihan Chen]

Hi,

I was trying to compare the output of the IFFT block and that from Matlab.
Here's what I get:
My input: [1,2,3,4]
output from Matlab: [2.5+0j, -0.5-0.5j, -0.5+0j, -0.5+0.5j]
output from gnuradio: [10+0j, 2+2j, -2+0j, 2-2j]
parameter for the FFT block: fft.fft_vcc(4, False, (()), True, 1)
It seems like the output is not correct. Do I miss something here?

So, in general, I want to check that if the output of ifft for [1 2 3 4]
from Matlab is [a b c d], then in gnuradio after fft-shift I should get [c
d a b], correct?

Please help. Thanks!

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

Re: [Discuss-gnuradio] aligning received ofdm frames

[Michael Dickens]

Hi Shane - Your GRC scripts are just replicating what GR OFDM does by
default, which is asynchronous detection on the Rx side. There is meta-
data being supplied by the header that could be used if you wanted to
modify the header/payload demux block. That said, unless you're going to
continuously stream OFDM symbols, you can't sync the Rx side to the Tx
side. If you're going to guarantee a continuous OFDM symbol stream, then
you'll need to change the sync parts on Rx & there should be a way to do
what you want. That said, it's not the way GR's default OFDM is designed
to work. I'm confident if you search around you can find GR OOT modules
that handle the sync you're looking for; you'll just need to tweak it
for your needs. Hope this is useful. - MLD
On Thu, Feb 1, 2018, at 8:05 PM, Shane Petcavich wrote:
> I'm using the attached two grc files for OFDM transmit and receive. I
> need to align a received symbol with the corresponding transmitted
> symbol to perform some math. From this link at the bottom it looks
> like the header meta deta that is passed back to the header demux
> block contains information such as the packet number, which may be
> useful. Is there a simple way to sink all received symbols / packets
> to a file and extract the meta data out to align each transmitted
> symbol with its corresponding received symbol?> 
> https://gnuradio.org/doc/doxygen/page_packet_data.html
> 
> Email had 2 attachments:
>  * ofdm_rx_test2.grc 124k (application/gnuradio-grc)
>  * ofdm_tx_test2.grc 55k (application/gnuradio-grc)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts

[Michael Dickens]

Hi Vipin - OK; interesting. Can you try the following:
{{{
sudo port -f deactivate uhd
sudo port install uhd-devel
}}}
then if those work, try running "uhd_fft" again & hopefully it will
work. If not, send me the crash log off-list & we'll try something
else. - MLD
On Fri, Feb 2, 2018, at 1:23 PM, Vipin Sharma wrote:
> Actually, the install works fine but I am running into segmentation
> violation while running top_block.py through GRC GUI or uhd_fft on
> command line. Somewhere I am guessing Python versions are getting
> messed up. Here is the crash log after running 'uhd_fft -f 868M -s
> 10M'; how do I figure out what is causing the crash?> 
> Process:   Python [98722]
> Path:  /opt/local/Library/Frameworks/Python.framework-
> /Versions/2.7/Resources/Python.app/Contents/MacOS/Python> Identifier: 
>org.python.python
> Version:   2.7.14 (2.7.14)
> Code Type: X86-64 (Native)
> Parent Process:bash [93492]
> Responsible:   Python [98722]
> User ID:   503
> 
> Date/Time: 2018-02-02 10:19:04.736 -0800
> OS Version:Mac OS X 10.12.6 (16G1114)
> Report Version:12
> Anonymous UUID:120FE2C9-C399-E258-2FCC-CB15EFBA9026
> 
> Sleep/Wake UUID:   F31F40DE-3B36-4430-A542-C83035144872
> 
> Time Awake Since Boot: 27 seconds
> Time Since Wake:   2000 seconds
> 
> System Integrity Protection: enabled
> 
> Crashed Thread:0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes:   KERN_INVALID_ADDRESS at 0x0037312e
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Signal:Segmentation fault: 11
> Termination Reason:Namespace SIGNAL, Code 0xb
> Terminating Process:   exc handler [0]
> 
> VM Regions Near 0x37312e:
> __LINKEDIT 0001266f3000-0001266ff000 [   48K]
> r--/rwx SM=COW  /System/Library/Extensions/IOUSBFamily.kext/Conte-
> nts/PlugIns/IOUSBLib.bundle/Contents/MacOS/IOUSBLib> --> 
> STACK GUARD7c905000-7c906000 [4K]
> ---/rwx SM=NUL  stack guard for thread 1> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>libgnuradio-blocks.3.7.11.dylib 0x0001188b7f36
>boost::asio::detail::task_io_service::init_task() + 134> 1   
> libgnuradio-blocks.3.7.11.dylib 0x0001188a4367
> boost::asio::io_service::service* boost::asio::detail::service_regist-
> ry::create >(boost::asio::io_service&) + 105> 2   libuhd.003.dylib   
> >0x000119442167 boost::asio::de-
> tail::service_registry::do_use_service(boost::asio::io_service::servi-
> ce::key const&, boost::asio::io_service::service*
> (*)(boost::asio::io_service&)) + 127
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New to Gnu

[D J]

Hello all,

I've been doing radio and satellite communications professionally for about
10 years now.  I've just started working with SDR and I have to say...wow.
Even after 10 years as an RF tech, and university training in Computer
Science, this stuff isn't easy to just "pick up".  Thanks to all of you who
actively work on developing Gnu Radio, OOT modules, answer questions on
forums/mailing lists, and maintain repositories to help this project.
You're making it easier for people like me.

Regards,

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

[Discuss-gnuradio] FOSDEM: Last reminder, and BoF meeting on Saturday

[Martin Braun]

Hi all,

last chance to buy a train ticket to Brussels :) This weekend, we'll
have FOSDEM as usual, with an SDR track that has a nice agenda:

https://fosdem.org/2018/schedule/track/software_defined_radio/

Also, Phil Balister has organized a small room for GNU Radio-specific
discussions on Saturday. here's the info:

> | 2018-02-03 | 12:00:00 | H.3227  | confirmed   | GNU Radio Meeting

Our agenda will depend on who shows up. If we see a lot of new faces,
we'll do some introductions, and more Q Most likely, we'll talk about
the organizational changes.

Looking forward to seeing you all!

Cheers,
Martin

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

[Discuss-gnuradio] Triggering between two transmitters

[sumit kumar]

Hi,

I want to create a deterministic collision scenario between wifi and
zigbee. I am using gr-ieee 80211 and gr-ieee 802154 along with USRP B210.

I have a constraint that my wifi preambles should always collide with an
ongoing zigbee transmission.

In order to do that, I am thinking of synchronizing the wifi transmitter
and zigbee transmitter (both connected in the same laptop) in such a way
that wifi transmits its frame only when zigbee transmission is ongoing.

Is there any way that zigbee transmitter triggers the wifi transmitter
whenever a zigbee frame is transmitted.

Air time of zigbee is very high compared to wifi, so I am sure if zigbee
transmitter triggers wifi transmitter, wifi preambles will collide with
zigbee for sure.

Both wifi transmitter and zigbee transmitter are connected to the same
laptop and using different USRP B210.

I am not sure if the solution lies in gnuradio or uhd hence posting at both
places :)

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

Re: [Discuss-gnuradio] GNU Radio Project Leadership Updates

[CEL]

Hello everyone!

I think it's time that I finally also lose a couple of words on this
topic:

Thanks everyone for making GNU Radio the most popular SDR framework
with certainly the most interesting community! This, especially,
applies to Johnathan, whose contributions on all levels, technically,
financially, as well as personally, are invaluable to the presence and
future of this framework.

I'm still a bit overwhelmed by the idea of managing the technical side
of all of this. As Ben said, we have a couple immediate issues to
tackle,  but this leadership change doesn't come with only a set of
freshly identified challenges, but also with a lot of opportunities,
which I'm planning to take. We'll try to divide the workload a bit more
evenly, which implies also dividing responsibilities, and I hope that
leads to a high development coordination capacity while keeping the
code quality up :)

So, a bit on what to expect in the next week(s):
First of all, although I really feel we should be getting 3.8 out as
soon as possible, that also means: Not a day earlier; we'll take the
time to merge pending PRs, release a 3.7.xx version, and define what
will be part of 3.8, and what will then be on the master branch for the
 release after that. 
There will be slight changes to the dev process, but details on that
are pending while I try to meet up with a bunch of people with whom I
want to coordinate this.
I will hurry myself as much as feasible, but some features simply take
time, and my mision is to foster long-term active development, which
means that it's equally important to not frustrate users nor
developers; the next thing we'll do is sit together and find what the
"minimum viable release" is that doesn't obstruct future development
and get that ready for the masses!

As said, we'll not abandon anything anytime soon, but we will focus on
developing "forward", whilst keeping 3.7 nicely running and bug-free.
Part of that plan is that I consider the 3.8 release to be "relatively
soon", but that really depends on the feature set we define to be in
3.8. I won't be doing that definition alone; we'll all discuss this.
Basically, I feel that the most important features of 3.8 are Python 3
and Qt5, but these also come with effects on a lot of other subsystems.
Note that anything that doesn't make it into the 3.8 release is far
from being abandoned – we'll definitely crank up the release frequency.

I feel I'm already being overly specific and lengthy; a lot of this
process will actually unfold in the next two, three weeks. Clearly,
we'll have to come up with some kind of documentation (and if it's just
a blog post) that explains how we want to proceed, and I promise we'll
do that, as things fall into place.

On a personal note, I'm super happy to be part of this, and I know I've
been handed an impressive piece of software, a fantastic and actually
historically rich ecosystem, and anyone who's been observing me on the
mailing list hopefully realizes how much I like the community. The
speed of all this surprises even me, so please bear with me while I
sort out how to actually *do* all this. There's really so much more
that one wishes one had the time (and army of developers) for to
implement than I'll be able to do within a couple years of time frame,
so the trick really is finding out what the project needs the most.

Therefore, the thing I'd really like to ask everybody right now is to
do is sit down and think about where they'd like the project to move
from here, and discuss that. We're setting up a very Python Enhancement
Process-alike thing so that such ideas don't go to waste, without
adding the bureaucratic overhead of having a hierarchical idea
collection process. It's certain that if anything, we must encourage
users to become contributors, no matter whether it's in shape of bug
reports, pull requests, requests for architectural features, or simply
by engaging with each other. Same goes for developers (which are users,
too): I'll need you to be as productive as possible, so I'll try to get
into your way as little as feasible. 

So, now I'll have to mentally prepare for FOSDEM; if you're there, come
see me, say hello, but please don't expect me to have qualified answers
for complex development questions just yet :)
Anyway, I **know** you'll either be in the SDR devroom at FOSDEM on
Sunday, or neglecting your social live by watching the videos, so

see you and:

Best regards,

Marcus
(freshly baked GNU Radio Project Maintainer)

On Wed, 2018-01-31 at 15:24 -0500, Ben Hilburn wrote:
> Hi all!
> 
> As usual, there is a lot going on in the project and community,
> including GSOC & SOCIS, GRCon planning, and new development. There
> are also some big changes happening in the project leadership that I
> want to announce.
> 
> First, our Chief Architect and Foundation CTO, Johnathan Corgan, is
> moving into a new role as a Technical Advisor for the project. He
> will no longer be leading the project's technical development, 

Re: [Discuss-gnuradio] wx_fft_sink block

[abhilash b]

Hello,
I am using USRP N210 with CBX daughter board.
In the GNU radio I use USRP_source block followed by wx_gui_fft sink block.
I input a power of -60dB to the USRP.  The input power is measured using a
spectrum analyzer.

The RF gain in the source block is kept at 0 dB, sample rate of 25 MHz and
center freq of 2.4 GHz

But the fft block shows the power to be -40dB.
Could you please tell me why such a huge offset.

-- 


-Regards
Abhilash B
___
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