Re: [Discuss-gnuradio] gnu radio installation on Mac via MacPorts
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?
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
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
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
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
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&A. 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
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
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, b
Re: [Discuss-gnuradio] wx_fft_sink block
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
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