Re: [Discuss-gnuradio] uhd time_spec

Yeah I read that page and I added UHD , but I got same error again. On Tue, May 30, 2017 at 17:20, Garver, Paul W mailto:garv...@gatech.edu>> wrote: Did you link against the appropriate libraries in cmake? Haven’t done this myself for UHD library calls, but my guess is you need t

Re: [Discuss-gnuradio] uhd time_spec

Did you link against the appropriate libraries in cmake? Haven’t done this myself for UHD library calls, but my guess is you need to add UHD to GR_REQUIRED_COMPONENTS, or something similar [1]. That error is a really poor message for diagnosing the root issue ,which is likely a linking problem.

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

Some point below… 1) I agree with Ben regarding the to-sigMF converters. I have ~22 TB of IQ samples + GNURadio metadata. Ideally, I’d be able to use such a tool to convert the GR metadata to sigMF. - I think you’d want some sort of key-value pair mapping from GR metadata to sigMF. For example,

Re: [Discuss-gnuradio] Timestamp on file sink for replaying data

Hi Alexis, You should check out the gr page on metadata [1]. In your flow graph, use a file meta sink. That should write the metadata, including time stamps, to disk. It's not great at high sample rates, though. I maintain gr-analysis [2], which has a program called specrec, which can handle hi

Re: [Discuss-gnuradio] Combining gr-IEEE802.11 with NS2/NS3 For Simulations

mailto:m...@bastibl.net>> wrote: Hi, On 2 Mar 2017, at 16:27, Garver, Paul W mailto:garv...@gatech.edu>> wrote: Hey all, I’m looking at doing some IEEE 802.11g simulations for my research and I’d like to solicit your opinion as to the best approach. Essentially, I think I have

[Discuss-gnuradio] Combining gr-IEEE802.11 with NS2/NS3 For Simulations

Hey all, I’m looking at doing some IEEE 802.11g simulations for my research and I’d like to solicit your opinion as to the best approach. Essentially, I think I have a method of improving localization accuracy combining TDoA with some information from the MAC Layer. I’d like to simulate my idea

Re: [Discuss-gnuradio] cyclostationary feature detection for cognitive radio

You might find gr-specest [1] helpful. [1] https://github.com/kit-cel/gr-specest [https://avatars0.githubusercontent.com/u/851588?v=3&s=400] GitHub - kit-cel/gr-specest: A module adding spectral ... github.com gr-spe

Re: [Discuss-gnuradio] Problem installing GR via pybombs on fresh load

an see saying that it is a pybombs issue, but you say that swig it is a > pre-req, that would be fine. On the other hand, it is a little odd that > pybombs is willing to say that everything installed fine when it obviously > didn't. > > On 02/08/2017 09:02 AM, Garver,

Re: [Discuss-gnuradio] Problem installing GR via pybombs on fresh load

I just saw this too a few days ago on Ubuntu (14.04/15.04, can’t remember). It appears to me that although GR builds, it builds without any Python support because SWIG isn’t found / installed. I don’t think this is a documentation issue - it’s a Pybombs issue. PWG > On Feb 8, 2017, at 8:52 AM,

Re: [Discuss-gnuradio] issue with boost::chrono::

yers, David Sent: Friday, January 20, 2017 12:45:23 PM To: Garver, Paul W; discuss-gnuradio@gnu.org Cc: Harper, Andrew Subject: Re: issue with boost::chrono:: Paul- You were right! It was a linking issue. In my OOT parent director, I modified the following line in the CMakeLists.txt file: f

Re: [Discuss-gnuradio] static peaks spectrum

I'm not too familiar with the RF front end on your particular device. I was thinking the spikes were perhaps intermods. Is your receiver OTA or cabled? You can change the gain and check the amount the peaks drop to see if that's the issue. There's some good info in the DRS sponsor presentation

Re: [Discuss-gnuradio] issue with boost::chrono::

My money is on this being a linking error. Did you ensure the proper linking is being done in the cmake file? Also, when I had I a similar problem this helped debug: in the python/ directory, look at the __init__.py file and remove the try / except around the "from xxx_swig import *". You

Re: [Discuss-gnuradio] static peaks spectrum

If you change the receiver gain, does anything happen to the peaks? Try lowering it. Paul Garver On Jan 19, 2017, at 4:32 AM, Marc Pàmies Massip mailto:mpamies...@gmail.com>> wrote: Oh, really? I was using a HackRF-One and sampling at 10MHz. Now I've tried with different sample rates (8MHz,

Re: [Discuss-gnuradio] gr-ieee802.11 Questions

I would be shocked if the Raspberry Pi 3 has the processing power to run gr-ieee80211. Are you attempting to do this real-time? PWG On Dec 12, 2016, at 10:31 AM, Eric Yates mailto:e...@lexistartup.com>> wrote: Hello, I'm running gr-ieee802.11 on a Raspberry Pi 3 running Raspbian. I'm connected

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

can't properly figure out what's symbol rate here, can't clearly distinguish 0 and 1s to count, then diff the time and find out symbol rate. I would really appreciate any help/hint/advise. Thank you! On Thu, Dec 1, 2016 at 4:16 PM, Garver, Paul W mailto:garv...@gatech.edu>>

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

On Dec 1, 2016, at 2:08 PM, AndroidT Tester mailto:itestandroid2...@gmail.com>> wrote: Hello Paul, Indeed it's working now :) I successfully converted my 16-bit IQ sample file to a Cfile :) Thanks for all your help!! On Thu, Dec 1, 2016 at 4:04 PM, Garver, Paul W mailto:garv...@ga

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

.cfile -o fc32 I get sample_cnt_end=50,final_index=1920991232 Empty Header, quitting. On Thu, Dec 1, 2016 at 1:35 PM, Garver, Paul W mailto:garv...@gatech.edu>> wrote: It probably can’t find the header. The command # gr_mkheader -r 1.8e6 -t sc16 -f 408e6 -l 1920991232 Sample-40

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

arameters. I did filesize / 4 for sample count. I did this first: gr_mkheader -r 1.8e6 -t sc16 -f 408e6 -l 1920991232 Sample-408MHz Then when I try to do: gr_fileman Sample-408MHz Sample.cfile I got the error above, what am I missing? On Thu, Dec 1, 2016 at 12:07 PM, Garver, Paul W mailto:ga

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

which is 16-bit IQ pair and then convert it to CFile? Do I concatenate the files? put myheader.hdr at top of my recording? Sorry again for these newbie questions On Thu, Dec 1, 2016 at 11:32 AM, Garver, Paul W mailto:garv...@gatech.edu>> wrote: Please copy the list next time so other folks

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

:34 AM, AndroidT Tester mailto:itestandroid2...@gmail.com>> wrote: Thank you very much! It worked :) On Wed, Nov 30, 2016 at 11:04 AM, Garver, Paul W mailto:garv...@gatech.edu>> wrote: Use a file source block with “short” type into an “Ishort to Complex” block. The Ishort to Com

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Use a file source block with “short” type into an “Ishort to Complex” block. The Ishort to Complex block will de-interleave the shorts into complex samples. PWG > On Nov 30, 2016, at 8:55 AM, AndroidT Tester > wrote: > > Hey guys, > > I have a sample file with IQ pairs, each I and Q is 16-bit

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

s is not at all ideal. I'd still be interested to hear from anyone who can solve the actual problem. This is my solution for now. Paul Garver > On Nov 22, 2016, at 11:29 PM, Sylvain Munaut <246...@gmail.com> wrote: > >> On Tue, Nov 22, 2016 at 9:30 PM, Garver, Paul W w

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

ones. Now we are really in the weeds! PWG On Nov 17, 2016, at 9:30 AM, Garver, Paul W mailto:garv...@gatech.edu>> wrote: The module library builds without linker errors. The block which calls viterbi_algorithm_combined() is rfid_decode. [12%] Linking CXX shared library libgnurad

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

why g++ can't find the symbol. From: Michael Dickens Sent: Thursday, November 17, 2016 11:04:09 AM To: Garver, Paul W Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux) The lib/ and s

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

I’m thinking I should write a simple C++ harness to call the block. That way, I can isolate a SWIG problem from a block/C++ issue. Should the SWIG link libraries (GR_SWIG_LIBRARIES) be different from the libraries used in the lib directory? PWG On Nov 14, 2016, at 10:05 PM, Garver, Paul W

Re: [Discuss-gnuradio] Enable/Disable File Saving in GUI

You first need a file sink block capable of doing this. I would probably make a file sink that can take in a message to start and stop recording. Then, just have a QT GUI widget send the appropriate message. It's possible you may be able to do this with a tagged file sink/ existing components, b

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

hat does your lib/CMakeLists.txt's "target_link_libraries" directive look like, exactly? Best regards, Marcus On 14.11.2016 22:38, Cinaed Simson wrote: > On 11/14/2016 06:34 AM, Garver, Paul W wrote: >> objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0 >

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

ype_tEPKSB_PT0_ From: Sylvain Munaut <246...@gmail.com> Sent: Monday, November 14, 2016 9:28:53 AM To: Garver, Paul W Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux) > ImportError: /usr/local/lib/libgnurad

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

ibnsl.so.1 (0x7f5df17bb000) ________ From: Sylvain Munaut <246...@gmail.com> Sent: Sunday, November 13, 2016 11:26:20 AM To: Garver, Paul W Cc: Cinaed Simson; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

ng it correctly. Paul Garver > On Nov 12, 2016, at 10:17 PM, Cinaed Simson wrote: > > Maybe the version of swig? > > On Debian Jessie, it's > > swig2.0 -version > > which generates > > SWIG Version 2.0.12 > > -- Cinaed > > >> O

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

discover the change and build a python wrapper for the method. So: make clean, cmake ../, make, sudo make install, sudo ldconfig. Good luck! Dan On 11/12/16 2:55 PM, Garver, Paul W wrote: > I've got an out-of-tree module which uses gr-trellis and gr-digital. In the > root OOT module directo

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

apped code is so obfuscated it is difficult to really see what is happening. PWG ________ From: Discuss-gnuradio on behalf of Garver, Paul W Sent: Saturday, November 12, 2016 5:36:28 PM To: Michael Dickens Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Linki

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

has to "rm -rf" the whole build > directory and start from go. Hope this is useful. - MLD > >> On Sat, Nov 12, 2016, at 02:55 PM, Garver, Paul W wrote: >> I’ve got an out-of-tree module which uses gr-trellis and gr-digital. In >> the root OOT module directory’s

[Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

I’ve got an out-of-tree module which uses gr-trellis and gr-digital. In the root OOT module directory’s CMakeLists.txt I’ve added: set(GR_REQUIRED_COMPONENTS RUNTIME TRELLIS DIGITAL) I’ve got a Mac OS X and Linux setup. On the MAC setup ( GR v3.7-MacPorts-devel-git-e106376b(20160809)), the OOT

[Discuss-gnuradio] Polyphase Clock Sync Eating Tags

I'm re-tuning a frequency translating FIR filter ("tuner") dynamically based on a channel detection. As documented, after the re-tune happens, the tuner sends a "freq" tag when the re-tune has completed. The problem is that I have a follow-on polyphase clock sync block which is eating that frequ

Re: [Discuss-gnuradio] gr-ieee 802.11 and threads for real time

You should read the accompanying academic papers, especially [1]. It should run in real-time with any sort of reasonable hardware. I'm not sure why you would want to re-implement the decoder. [1] http://www.ccs-labs.org/bib/bloessl2013towards/bloessl2013towards.pdf Towards an Open Source IE

Re: [Discuss-gnuradio] Question about GNURADIO File sink

While writing a custom block would give you some valuable experience, there are some other options. 1) You may be able to use some combination of the tag strobe block [1] together with the tagged file sink [2]. I'm thinking you could have two tag strobe blocks, one for the "burst" TRUE, and on

Re: [Discuss-gnuradio] Doppler shift on waterfall plot with audio signal

I'm not familiar with your application. But you would get better frequency resolution for the same length FFT if you decimate after the BPF. It would probably be easier to see what is going on. Is there a reason you are significantly oversampled? Paul Garver > On Oct 21, 2016, at 3:31 PM, Chr

Re: [Discuss-gnuradio] Polyphase Clock Sync for Bursts

ength. From: Usman Haider Sent: Sunday, October 9, 2016 9:26:47 AM To: Garver, Paul W Cc: Sylvain Munaut; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Polyphase Clock Sync for Bursts Yes, you are right here. "The time_est tag can be used to adjust the sampli

Re: [Discuss-gnuradio] Polyphase Clock Sync for Bursts

So is that what the time_est tag in corr_est_cc is for? The idea being correlate against the preamble to generate an initial timing estimate for the clock recovery to lock quickly? PWG > On Oct 7, 2016, at 3:37 PM, Sylvain Munaut <246...@gmail.com> wrote: > >> Does anyone have insight into how

[Discuss-gnuradio] Polyphase Clock Sync for Bursts

I want to use the polyphase clock sync block to match filter and clock sync on a bursty signal. The pulse shape is basically square, but from our discussion [1], providing RRC taps works pretty well. I have snippets (~20k samples) of the signal from an energy detector, which contain the burst

Re: [Discuss-gnuradio] Block Thread question

Does you block take the packet length as a parameter (vs. reading from metadata)? I think this is a block which should exist in the GR baseline, if your implementation is general enough. PWG On Oct 4, 2016, at 12:44 PM, Marcus Müller mailto:marcus.muel...@ettus.com>> wrote: Hi Jake, yes, that'

Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

I have tried to use PFB clock sync without success on rectangular pulses as well. Presumably you've seen the documentation [1] on nfilts and taps. I tried making the filter a rectangular pulse with x sps upsampled by nfilts. One theory I have is that the polyphase clock sync may not work with re

Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

I'm a bit confused by your calculation. Nyquist for complex data is equal to the analog bandwidth so you only need a sample rate of 25.6 MSPS as stated. USB 3.0 will handle this without a problem on the B200. If you use short (16 bit integers) IQ then you have 4 bytes/complex sample so ~100MB/se

Re: [Discuss-gnuradio] slicing up a 'file-sink' capture?

If you need more advanced processing to detect the burst, you might consider gr-eventstream [1]. It can chunk up bursts/events based on a trigger and write to a file,display, or process. [1] https://github.com/osh/gr-eventstream Paul Garver On Sep 23, 2016, at 8:53 PM, Kevin Reid mailto:kpr.

Re: [Discuss-gnuradio] gr-trellis: Linking errors with viterbi_algorithm_combined()

ust adding TRELLIS and DIGITAL to GR_REQUIRED_COMPONENTS in the OOT module's root CMakeLists.txt is sufficient for proper linking, as [1] notes. On Sep 5, 2016, at 11:23 AM, Garver, Paul W wrote: I am writing a block (pwg) in an OOT module (gr-research) which calls viterbi_algorithm_combined(

[Discuss-gnuradio] gr-trellis: Linking errors with viterbi_algorithm_combined()

I am writing a block (pwg) in an OOT module (gr-research) which calls viterbi_algorithm_combined() in gr-trellis. I can’t seem to get the linker to cooperate. I’ll admit my C++ template skills are a bit rusty, so maybe this is a simple linking-against-a-template issue. Is there something differe

[Discuss-gnuradio] gr-trellis: Linking errors with viterbi_algorithm_combined()

I am writing a block (pwg) in an OOT module (gr-research) which calls viterbi_algorithm_combined() in gr-trellis. I can't seem to get the linker to cooperate. I'll admit my C++ template skills are a bit rusty, so maybe this is a simple linking-against-a-template issue. Is there something differe

Re: [Discuss-gnuradio] Higher sample rate

You might try specrec in the gr-analysis module. It is optimized for fast writes but is Linux only. We routinely do 2.5 minute records at 25 MSPS sc16 format (100 Mbytes/sec sustained) with a b200 without typically dropping any samples. As mentioned, your hardware makes a big difference. We do t

Re: [Discuss-gnuradio] error with running wifi_loopback.grc from gr-ieee802-11

Make sure logging is disabled on ALL blocks. I haven't seen that libstdcxx error before, but I do have the segfaults with the logging in Ubuntu 15.04 with pybombs install. Paul Garver > On Aug 13, 2015, at 7:33 AM, Tian Alvin wrote: > > Hi Paul, > > Thanks very much for your help! I have d

[Discuss-gnuradio] Proposed Offline Tools: Header Generation, File Manipulation and Format Conversion

To use GNURadio as a data analysis platform, I've been developing a few tools which I think will be useful for the general community. These are primarily Python/command line tools intended to manipulate prerecorded files. I'm airing them out here for some feedback to ensure I'm not duplicating

Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis

quot; Sent: Monday, November 10, 2014 12:52:39 PM Subject: Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis On Mon, Nov 10, 2014 at 12:43 PM, Garver, Paul W < garv...@gatech.edu > wrote: Sorry my response was really confusing after re-reading it -- let me try again. We use t

Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis

a powerful analysis platform. PWG - Original Message - From: "Tom Rondeau" To: "Paul W Garver" Cc: "GNURadio Discussion List" Sent: Monday, November 10, 2014 11:46:18 AM Subject: Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis On Wed, Nov 5,

Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis

"Tom Rondeau" To: "Paul W Garver" Cc: "GNURadio Discussion List" Sent: Monday, November 3, 2014 6:16:38 PM Subject: Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis On Wed, Oct 29, 2014 at 1:23 PM, Garver, Paul W < garv...@gatech.edu > wrote: I'

Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis

wtText(QString("").sprintf("%e",secs)) Additional tasks: Problem: In gr_spectrogram_plot, the spectrogram is hardcoded to 200 FFTs. Make this a configurable parameter. Problem: In gr_spectrogram_plot, the timescale does not update properly with the file seek widget.

[Discuss-gnuradio] gr-qtgui Waterfall Time Axis

I have some large spectrum records and I would like to use GR for analysis in a a sort of "off-line" mode. I want to visualize the data using the spectrogram and then identify subsets of interesting features (e.g. WiFi Packets in 2.4 GHz) by frequency and time coordinates. Essentially, I want

Re: [Discuss-gnuradio] Discuss-gnuradio aUaU FM receiver

Pablo, I've also experienced the same issue with VMWare Player and Ubuntu 12.04 LTS x86_64 on a quad core i7 with a USRP N210. I've also tried Linux KVM to no avail. I ended up creating a USB 3.0 flash drive for my SDR development environment which had no issues. However, if you are interest