Re: [Discuss-gnuradio] New random number generator

> I'd say we rather want better > randomness than faster noise sources If that's the case, I'd recommend that Stefan uses the normal_distribution variate from boost (Stefan, see my example), rather than doing his own "normalization" of the RV, and we use that. Regarding Boost's mt19937 and the

Re: [Discuss-gnuradio] New random number generator

Hi Stefan, hehe, I thought you might have an idea how to benchmark memory consumption. So I'm stuck with this myself :) What I can definitely say is that the -O3 variant of boost definitely can't allocate much memory, based on the time it needs -- frequent allocations would probably have caught

Re: [Discuss-gnuradio] New random number generator

On 09/02/2015 01:35 PM, Marcus Müller wrote: I'd say we rather want better randomness than faster noise sources If that's the case, I'd recommend that Stefan uses the normal_distribution variate from boost (Stefan, see my example), rather than doing his own "normalization" of the RV, and we use

Re: [Discuss-gnuradio] New random number generator

Hi all, for me, these results don't look that bad. Consider that the quality of the random numbers is increased enormously and with an ordinary simulation you loop the period length of the current generator (about 1e8 samples) multiple times. The results should be highly correlated if you use

Re: [Discuss-gnuradio] New random number generator

Hi Andre! Wow, that's a bit much to read right now. The problem I have with using AVX2 would be portability, which would be no issue if we wrapped RNG in a VOLK kernel and offered a good baseline competitor in portable C code. Point is though that our alternative in RNG seems to be

Re: [Discuss-gnuradio] New random number generator

On Wed, Sep 2, 2015 at 12:39 PM, Marcus Müller wrote: > Hi Andre! > > Wow, that's a bit much to read right now. The problem I have with using > AVX2 would be portability, which would be no issue if we wrapped RNG in > a VOLK kernel and offered a good baseline competitor

Re: [Discuss-gnuradio] New random number generator

On 09/02/2015 01:41 PM, Marcus D. Leech wrote: On 09/02/2015 01:35 PM, Marcus Müller wrote: I'd say we rather want better randomness than faster noise sources If that's the case, I'd recommend that Stefan uses the normal_distribution variate from boost (Stefan, see my example), rather than

Re: [Discuss-gnuradio] Changing GUI structure on the fly

Hi Przemek, this might leave the kind of things that you can "easily" do with the GUI tools in the GNU Radio companion. If you want to keep things in the GRC, I'd recommend using different taps for the different groups of widgets. Basically, if you use the QT GUI stuff, you should be able to

Re: [Discuss-gnuradio] New random number generator

On 02.09.2015 05:10, Stefan Wunsch wrote: > Now my question: Before doing a pull request, do you have any concerns > regarding memory use or processing load? Obviously the new > implementation isn't that light-weight as the ten lines of code before. > But the current implementation can not be used

Re: [Discuss-gnuradio] Possible typos in a GRCon15 presentation?

Hi Jeon - It is quite possible that some presentations contain minor typos or even errors. Research/development and presentation of it is imperfect at best. Discussion such as this is the right thing to do! If anyone catches minor typos or errors in any GRCon15 presentation (or, for that matter,

Re: [Discuss-gnuradio] Possible typos in a GRCon15 presentation?

Hi Jeon, Here's a long-winded answer. You're correct, but I wanted to make sure the terminology was clear. Tag offsets in add_item_tag() are absolute, relative to the beginning of the sample stream, not relative to input or output buffers. But it's probably safer to think in terms of

Re: [Discuss-gnuradio] FSK receiver

Hi Rich, I am continue with the transmitting part ? However, I cannot fine the FSK modulate block or Quadrature mod in GNU radio companion. Is there another block that use for FSK modulation in GNU radio ? I found DPSK mod, GFSK mod, GMSK mod ... however not FSK. Do you have any example for

[Discuss-gnuradio] Meta file time stamp

Dear All, We are experiencing unexpected behavior with the time stamps in the meta file headers. It appears that in cases where the flowgraph experiences data drops, the timestamp is properly updated. However, in cases, where the flowgraph hits the maximum segment size (4 MB in our

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

Hi! We just received our brand new E310 and we are wondering what is the "right" approach for developing applications to be run on it. In fact we are a bit used to working with a B220 but that operating condition was a different: C(++) code and/or GNURadio (with the its graphical Companion)

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

Hi Maurizio, glad to see you ask these questions! For those who read this later but aren't involved in Maurizio's/mine email exchange: you get the SDK under [1] in its current version, installation instructions under[2]. So, you're right. With the E310, you'll need to use a cross-compiler to

Re: [Discuss-gnuradio] New random number generator

Hi Stefan, strange, I was looking at the same code just a few days ago, when I needed to find out whether I understood filters well enough by pushing noise through. Here's my small testcases (thankfully I didn't restart my machine since then -- these were still in /tmp). So, in fact, I tested

Re: [Discuss-gnuradio] block without work function won't stop

Huh, I'm out of my depth here. However, yes, every subclass of gr::block automatically has a pmt::mp("system") message port, that you can use to do such things. Best regards, Marcus On 02.09.2015 14:47, Nemanja Savic wrote: > Namely, > > my workless function block blocks my flowgraph when I call

[Discuss-gnuradio] New random number generator

Hi! I have discovered that the implemented random number generator in gnuradio (see file [0]) is almost older than me. As written in the code, the implementation is taken from 'Numerical recipes in C' (see version from 1992). The problem is that this algorithm is really bad compared to current

Re: [Discuss-gnuradio] block without work function won't stop

Hello again, could you please Marcus, or somebody else, give me some hint for sending done message to a block's "system" port. Are all blocks by default subscribed to system port? Best, Nemanja On Tue, May 26, 2015 at 2:37 PM, Nemanja Savic wrote: > Hi, > > thank you

Re: [Discuss-gnuradio] block without work function won't stop

Namely, my workless function block blocks my flowgraph when I call unlock(). I made a method where I set d_finished to True, but this doesn't help. Nemanja On Wed, Sep 2, 2015 at 2:16 PM, Nemanja Savic wrote: > Hello again, > > could you please Marcus, or somebody else,

[Discuss-gnuradio] Changing GUI structure on the fly

Hello I have a question: I have to program one application, that will switch between about 20 modulations. With 20 modulations, program will have a lot of parameters to change, so GUI needs to change during runtime. Is it possible to do somethink like that ?? Are there any design patterns for

Re: [Discuss-gnuradio] USRP timing offset

Hi Leonard, you should try to use set_start_time(time_spec_t(x)) on both the USRP sink and source, but only after setting a device time using set_time_now() before, that should be sufficiently (>0.1s) earlier than x, before you start the flow graph. Best regards, Marcus On 02.09.2015 16:41,

Re: [Discuss-gnuradio] New random number generator

Hi guys, a few days ago I stumbled over an RNG implementation [2] that uses some of the newer AVX2 instructions. I guess this would improve performance radically. There is also a paper on the matter [1]. Cheers Andre [1] http://agner.org/random/theory/randomvector.pdf [2]

[Discuss-gnuradio] Consolidated Logic at GRCon

Hello All, My name is Ryan Marlow, I'm a founder of Consolidated Logic, a new company based out of Blacksburg, VA working on an FPGA productivity tool we call RDA: Rapid Design Assembly. We had a booth at GRCon this year where we presented our tool working with Ettus's RFNoC framework for USRPs in