[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 algorithms. E.g. the period length is 1e8 compared to an up-to-date algorithm (Mersenne twister) with a period length of about 1e6000. I have fixed this [1] using boost.random and the mentioned Mersenne twister. Furthermore I have written some test-cases and fixed the transformation to Laplacian random numbers (the current implementation is wrong). As well, I have added the random class to swig so that you can use this in python. 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 in any serious simulation or publication, which is highly dependent on good random numbers. Some information about the performance is given on this page: [2]. Look for the generator mt19937 in table 24.5. Best regards Stefan [0] gnuradio/gnuradio-runtime/lib/math/random.cc [1] https://github.com/stwunsch/gnuradio/tree/newRandom [2] http://www.boost.org/doc/libs/1_59_0/doc/html/boost_random/reference.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 Marcus for your fast answer. Well, the problem is that nobody
> ecept scheduler knows when the flowgraph has finished, so I don't know who
> should sent that message to the block. This is however not of crucial
> importance for me. Namely I wanted to test some of my custom blocks, and
> test flowgraph necever reached completion, but as soon as message accepting
> dummy block was out everything was fine.
>
> Best,
> Nemanja
>
> On Tue, May 26, 2015 at 2:29 PM, Marcus Müller
> wrote:
>
>> Hi Nemanja,
>>
>> the point is that with message passing, it's not clear that your block is
>> ever finished.
>> Hence in block.cc, we have a mechanism to retrieve the "finishedness" of
>> a pure-message-block.
>>
>> bool
>> block::finished()
>> {
>> if((detail()->ninputs() != 0) || (detail()->noutputs() != 0))
>> return false;
>> else
>> return d_finished;
>> }
>>
>>
>> So, you'll have to set the d_finished variable of your block; sadly,
>> that's a private one by design (I think there are thread-safety reasons
>> this is not directly exposed, but I'm not sure -- I'd have to as T[io]m
>> about that).
>> The proper way to do so is to send your block a message to its
>> pmt::mp("system") port, containing pmt::mp("done").
>>
>>
>> Best regards,
>> Marcus
>>
>>
>> On 05/26/2015 02:10 PM, Nemanja Savic wrote:
>>
>> Hi all,
>>
>> I have a block that is used only for acepting messages and writing their
>> content into database. The block is written in python and it has no work
>> function, but only constructor and message handler. However when I run my
>> flowgraph it won't finish until I terminate it. When I exclude this block
>> it runs to completion normally.
>> Is there any issue with messages in this case. Should I manually delete
>> messages from the message queue or something like that.
>>
>> Best,
>>
>> --
>> Nemanja Savić
>>
>>
>> ___
>> Discuss-gnuradio mailing
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Nemanja Savić
>
--
Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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, 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 Marcus for your fast answer. Well, the problem is that nobody
>> ecept scheduler knows when the flowgraph has finished, so I don't know who
>> should sent that message to the block. This is however not of crucial
>> importance for me. Namely I wanted to test some of my custom blocks, and
>> test flowgraph necever reached completion, but as soon as message accepting
>> dummy block was out everything was fine.
>>
>> Best,
>> Nemanja
>>
>> On Tue, May 26, 2015 at 2:29 PM, Marcus Müller
>> wrote:
>>
>>> Hi Nemanja,
>>>
>>> the point is that with message passing, it's not clear that your block
>>> is ever finished.
>>> Hence in block.cc, we have a mechanism to retrieve the "finishedness" of
>>> a pure-message-block.
>>>
>>> bool
>>> block::finished()
>>> {
>>> if((detail()->ninputs() != 0) || (detail()->noutputs() != 0))
>>> return false;
>>> else
>>> return d_finished;
>>> }
>>>
>>>
>>> So, you'll have to set the d_finished variable of your block; sadly,
>>> that's a private one by design (I think there are thread-safety reasons
>>> this is not directly exposed, but I'm not sure -- I'd have to as T[io]m
>>> about that).
>>> The proper way to do so is to send your block a message to its
>>> pmt::mp("system") port, containing pmt::mp("done").
>>>
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 05/26/2015 02:10 PM, Nemanja Savic wrote:
>>>
>>> Hi all,
>>>
>>> I have a block that is used only for acepting messages and writing their
>>> content into database. The block is written in python and it has no work
>>> function, but only constructor and message handler. However when I run my
>>> flowgraph it won't finish until I terminate it. When I exclude this block
>>> it runs to completion normally.
>>> Is there any issue with messages in this case. Should I manually delete
>>> messages from the message queue or something like that.
>>>
>>> Best,
>>>
>>> --
>>> Nemanja Savić
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>
>
>
> --
> Nemanja Savić
>
--
Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 the performance of boost's mt19937 + boost's
normal distribution variate, and basically, it's relatively slow,
indeed; generating 1e8 complex random numbers (meaning 200e8 random
floats) with a single thread takes
g++ (GCC) 5.1.1 20150618 (x86_64)
test_rnd (Boost)
g++ -OXXX test_rnd.cpp
test_gr (gr::random)
g++ $(pkg-config --cflags --libs gnuradio-runtime) -OXXX te_gr.cpp
-O3 (optimized for speed)
1.25 s
5.92 s
-O0 (explicitly unoptimized) (default)
23.62 s
7.13 s
Someone who cares for speed could get a 5x increase of speed by using
boost, because that person would be using optimization, anyways.
However, I can't really explain what happens with boost and the
unoptimized case; it's really three times as bad as the current
implementation.
However, asking perf about this, the -O3 version spends nearly all of
its time in main(), whereas the -O0 spends most of it in some boost
functions -- which means that -O3 definitely inlines the calculations,
and from the disassembly alone I'd say all the stack operations needed
to jump in and out of routines seem to contribute significantly to the
problem.
Of course, that's not really a benchmark for all systems. What about 32
bit? What about ARM? What about clang? Can anyone try to make a Windows
build?
Best regards,
Marcus
On 02.09.2015 14:10, Stefan Wunsch wrote:
> 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 algorithms. E.g. the period length is 1e8 compared to an
> up-to-date algorithm (Mersenne twister) with a period length of about
> 1e6000.
>
> I have fixed this [1] using boost.random and the mentioned Mersenne
> twister. Furthermore I have written some test-cases and fixed the
> transformation to Laplacian random numbers (the current implementation
> is wrong). As well, I have added the random class to swig so that you
> can use this in python.
>
> 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 in any serious simulation
> or publication, which is highly dependent on good random numbers. Some
> information about the performance is given on this page: [2]. Look for
> the generator mt19937 in table 24.5.
>
> Best regards
> Stefan
>
> [0] gnuradio/gnuradio-runtime/lib/math/random.cc
> [1] https://github.com/stwunsch/gnuradio/tree/newRandom
> [2]
> http://www.boost.org/doc/libs/1_59_0/doc/html/boost_random/reference.html
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
#include
#include
#include
int main(int argc, char** argv){
int rate = 100*1000*1000;
std::vector< std::complex > noise(rate);
//initialize random number generator, seed 0, for reproducability
boost::mt19937 random_num_gen(0);
// limit sigma of the normal distribution, so that nearly all values fall into (-1;1)
// A distribution object is applicable to a random number generator (which inherently produces uniform output)...
boost::normal_distribution normal_distribution(0.0, 0.25);
//...using a variate generator
boost::variate_generator< boost::mt19937&, boost::normal_distribution >
variate_normal(random_num_gen, normal_distribution);
//get two random numbers, one for real, one for imag part, per sample
for(int sample = 0; sample < rate; sample++)
noise[sample]=std::complex(variate_normal(), variate_normal());
}
#include
#include
#include
#include
int main(int argc, char** argv){
int rate = 100*1000*1000;
std::vector< std::complex > noise(rate);
gr::random rnd(0); //initialize
for(int i = 0; i < rate; i++) {
noise[i]=std::complex(rnd.gasdev(), rnd.gasdev());
}
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 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, 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 Marcus for your fast answer. Well, the problem is
> that nobody ecept scheduler knows when the flowgraph has
> finished, so I don't know who should sent that message to the
> block. This is however not of crucial importance for me.
> Namely I wanted to test some of my custom blocks, and test
> flowgraph necever reached completion, but as soon as message
> accepting dummy block was out everything was fine.
>
> Best,
> Nemanja
>
> On Tue, May 26, 2015 at 2:29 PM, Marcus Müller
> mailto:marcus.muel...@ettus.com>>
> wrote:
>
> Hi Nemanja,
>
> the point is that with message passing, it's not clear
> that your block is ever finished.
> Hence in block.cc, we have a mechanism to retrieve the
> "finishedness" of a pure-message-block.
>
> bool
> block::finished()
> {
> if((detail()->ninputs() != 0) || (detail()->noutputs()
> != 0))
> return false;
> else
> return d_finished;
> }
>
>
> So, you'll have to set the d_finished variable of your
> block; sadly, that's a private one by design (I think
> there are thread-safety reasons this is not directly
> exposed, but I'm not sure -- I'd have to as T[io]m about
> that).
> The proper way to do so is to send your block a message to
> its pmt::mp("system") port, containing pmt::mp("done").
>
>
> Best regards,
> Marcus
>
>
> On 05/26/2015 02:10 PM, Nemanja Savic wrote:
>> Hi all,
>>
>> I have a block that is used only for acepting messages
>> and writing their content into database. The block is
>> written in python and it has no work function, but only
>> constructor and message handler. However when I run my
>> flowgraph it won't finish until I terminate it. When I
>> exclude this block it runs to completion normally.
>> Is there any issue with messages in this case. Should I
>> manually delete messages from the message queue or
>> something like that.
>>
>> Best,
>>
>> --
>> Nemanja Savić
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> Nemanja Savić
>
>
>
>
> --
> Nemanja Savić
>
>
>
>
> --
> Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[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 GNU Radio. Our tool is available for install and use, just go to our website at conic-labs.com where we have a set of tutorials to get you started. Here's a link to a promotional video we put together: https://youtu.be/la02IciYSOw Thanks, Ryan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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] http://agner.org/random/ On 02.09.2015 15:28, Marcus Müller wrote: > 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 the performance of boost's mt19937 + boost's > normal distribution variate, and basically, it's relatively slow, > indeed; generating 1e8 complex random numbers (meaning 200e8 random > floats) with a single thread takes > > g++ (GCC) 5.1.1 20150618 (x86_64) > test_rnd (Boost) > g++ -OXXX test_rnd.cpp > test_gr (gr::random) > g++ $(pkg-config --cflags --libs gnuradio-runtime) -OXXX te_gr.cpp > -O3 (optimized for speed) > 1.25 s > 5.92 s > -O0 (explicitly unoptimized) (default) > 23.62 s > 7.13 s > > > Someone who cares for speed could get a 5x increase of speed by using > boost, because that person would be using optimization, anyways. > However, I can't really explain what happens with boost and the > unoptimized case; it's really three times as bad as the current > implementation. > However, asking perf about this, the -O3 version spends nearly all of > its time in main(), whereas the -O0 spends most of it in some boost > functions -- which means that -O3 definitely inlines the calculations, > and from the disassembly alone I'd say all the stack operations needed > to jump in and out of routines seem to contribute significantly to the > problem. > > Of course, that's not really a benchmark for all systems. What about 32 > bit? What about ARM? What about clang? Can anyone try to make a Windows > build? > > Best regards, > Marcus > > On 02.09.2015 14:10, Stefan Wunsch wrote: >> 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 algorithms. E.g. the period length is 1e8 compared to an >> up-to-date algorithm (Mersenne twister) with a period length of about >> 1e6000. >> >> I have fixed this [1] using boost.random and the mentioned Mersenne >> twister. Furthermore I have written some test-cases and fixed the >> transformation to Laplacian random numbers (the current implementation >> is wrong). As well, I have added the random class to swig so that you >> can use this in python. >> >> 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 in any serious simulation >> or publication, which is highly dependent on good random numbers. Some >> information about the performance is given on this page: [2]. Look for >> the generator mt19937 in table 24.5. >> >> Best regards >> Stefan >> >> [0] gnuradio/gnuradio-runtime/lib/math/random.cc >> [1] https://github.com/stwunsch/gnuradio/tree/newRandom >> [2] >> http://www.boost.org/doc/libs/1_59_0/doc/html/boost_random/reference.html >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[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 problem like this ? Many thanks Przemek Lewandowski ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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, Leonard Foxes wrote: > > Hi everyone! > > > I’m new to Gnuradio e USRP. I use a USRP N210 with WBX daughterboards > and loop back cable to connect TX e RX. I have tested USRP with a > simple flowgraph (sine , usrp_sink , usrp_source) and I have observed > that the output signal from usrp_source block is time shifted. I > mean, the usefull output signal starts after 0.0105 seconds. How can > avoid this? I have tried to use “issued_stream_cmd”, setting > time_spec=0.0105 s but nothing has changed. > > > I want to use this USRP in a more complex project and I need to remove > this initial time-shift. > > > I attach a plot of input and output signal and my flowgraph. > > > Thanks in advance for help, > > > Leo > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 approximately the same periodicity in your simulation! That is a bug that you hardly see at first sight. It is possible to use the mt11213b generator, but this results only in a performance increase of 7% (see boost reference page). I don't think that it is worth using this one. Can you benchmark the used memory with your code (don't know how this works)? I think this isn't that important, but would be interesting. Greetings Stefan On 02.09.2015 15:28, Marcus Müller wrote: > 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 the performance of boost's mt19937 + boost's > normal distribution variate, and basically, it's relatively slow, > indeed; generating 1e8 complex random numbers (meaning 200e8 random > floats) with a single thread takes > > g++ (GCC) 5.1.1 20150618 (x86_64) > test_rnd (Boost) > g++ -OXXX test_rnd.cpp > test_gr (gr::random) > g++ $(pkg-config --cflags --libs gnuradio-runtime) -OXXX te_gr.cpp > -O3 (optimized for speed) > 1.25 s > 5.92 s > -O0 (explicitly unoptimized) (default) > 23.62 s > 7.13 s > > > Someone who cares for speed could get a 5x increase of speed by using > boost, because that person would be using optimization, anyways. > However, I can't really explain what happens with boost and the > unoptimized case; it's really three times as bad as the current > implementation. > However, asking perf about this, the -O3 version spends nearly all of > its time in main(), whereas the -O0 spends most of it in some boost > functions -- which means that -O3 definitely inlines the calculations, > and from the disassembly alone I'd say all the stack operations needed > to jump in and out of routines seem to contribute significantly to the > problem. > > Of course, that's not really a benchmark for all systems. What about 32 > bit? What about ARM? What about clang? Can anyone try to make a Windows > build? > > Best regards, > Marcus > > On 02.09.2015 14:10, Stefan Wunsch wrote: >> 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 algorithms. E.g. the period length is 1e8 compared to an >> up-to-date algorithm (Mersenne twister) with a period length of about >> 1e6000. >> >> I have fixed this [1] using boost.random and the mentioned Mersenne >> twister. Furthermore I have written some test-cases and fixed the >> transformation to Laplacian random numbers (the current implementation >> is wrong). As well, I have added the random class to swig so that you >> can use this in python. >> >> 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 in any serious simulation >> or publication, which is highly dependent on good random numbers. Some >> information about the performance is given on this page: [2]. Look for >> the generator mt19937 in table 24.5. >> >> Best regards >> Stefan >> >> [0] gnuradio/gnuradio-runtime/lib/math/random.cc >> [1] https://github.com/stwunsch/gnuradio/tree/newRandom >> [2] >> http://www.boost.org/doc/libs/1_59_0/doc/html/boost_random/reference.html >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 integrate the GUI tools into an Qt application that you might design with Qt Creator etc. I must admit that I haven't tried to build complex GUI applications with GR myself, so I can only point you to what I guess needs to be done, based on what I did a while back myself with something not-GR related: * build your flow graph with QtGUI visualizations; generate the python file. Open that file. * comment out all the GUI building stuff, ie. all after self.setWindowTitle(...) and before self.settings=... * build your GUI with QtCreator (Qt4, not 5!)[1]; add one of the Layouts (e.g. QHBoxLayout, by dragging "Horizontal Layout" onto your form) for your visualizations. Save. * Use pyuic4 to convert the .ui file to a python module. You'll get a class with a setupUi method * import that module in your python file. Instantiate the class, e.g. myForm = Ui_Form() * set up the GUI by doing myForm.setupUi(self) where you formerly commented out the GUI building stuff * find the places where "addWidget" was generated by GRC. Replace the things to which your QtWidgets are added by the appropriate Layout/Container instances from your Qt Form (e.g. the name of your QHBoxLayout above) * hope for the best :) Maybe someone who actually did more work with PyQT can comment on this. Best regards, Marcus [1] creating the form should look something like: Form creation dialog On 02.09.2015 16:53, Przemek Lewandowski wrote: > 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 problem like this ? > > Many thanks > Przemek Lewandowski > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 my eye. I'm afraid real numbers are impossible to get without the help of tools like valgrind, which bend/replace libc/syscalls... and hence stretch the execution duration massively. However, I think "/usr/bin/time -v" (the ZSH builtin time isn't as capable) gives some information, too: For the boost thing, it says, with little difference between -03 and -O0 (O0 gives 783772 kB, so even a bit more) Maximum resident set size (kbytes): 783760 For the GNU Radio-random.h based approach: -O0 = 789352 kB, -O3 = 789380 kB Considering that 1e8 complex are 781,250 kB boost O0 = 2522 kB overhead boost O3 = 2510 kB overhead gr::random O0 = 8102 kB overhead gr::random O3 = 8130 kB overhead The 5.5MB delta might be explained by the fact that I didn't link statically (that would've been unfair, I thought), and the gr::random rtloads a lot libraries. Greetings, Marcus On 02.09.2015 17:12, Stefan Wunsch wrote: > 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 approximately the same periodicity in your simulation! That is a > bug that you hardly see at first sight. > > It is possible to use the mt11213b generator, but this results only in a > performance increase of 7% (see boost reference page). I don't think > that it is worth using this one. > > Can you benchmark the used memory with your code (don't know how this > works)? I think this isn't that important, but would be interesting. > > Greetings > Stefan > > On 02.09.2015 15:28, Marcus Müller wrote: >> 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 the performance of boost's mt19937 + boost's >> normal distribution variate, and basically, it's relatively slow, >> indeed; generating 1e8 complex random numbers (meaning 200e8 random >> floats) with a single thread takes >> >> g++ (GCC) 5.1.1 20150618 (x86_64) >> test_rnd (Boost) >> g++ -OXXX test_rnd.cpp >> test_gr (gr::random) >> g++ $(pkg-config --cflags --libs gnuradio-runtime) -OXXX te_gr.cpp >> -O3 (optimized for speed) >> 1.25 s >> 5.92 s >> -O0 (explicitly unoptimized) (default) >> 23.62 s >> 7.13 s >> >> >> Someone who cares for speed could get a 5x increase of speed by using >> boost, because that person would be using optimization, anyways. >> However, I can't really explain what happens with boost and the >> unoptimized case; it's really three times as bad as the current >> implementation. >> However, asking perf about this, the -O3 version spends nearly all of >> its time in main(), whereas the -O0 spends most of it in some boost >> functions -- which means that -O3 definitely inlines the calculations, >> and from the disassembly alone I'd say all the stack operations needed >> to jump in and out of routines seem to contribute significantly to the >> problem. >> >> Of course, that's not really a benchmark for all systems. What about 32 >> bit? What about ARM? What about clang? Can anyone try to make a Windows >> build? >> >> Best regards, >> Marcus >> >> On 02.09.2015 14:10, Stefan Wunsch wrote: >>> 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 algorithms. E.g. the period length is 1e8 compared to an >>> up-to-date algorithm (Mersenne twister) with a period length of about >>> 1e6000. >>> >>> I have fixed this [1] using boost.random and the mentioned Mersenne >>> twister. Furthermore I have written some test-cases and fixed the >>> transformation to Laplacian random numbers (the current implementation >>> is wrong). As well, I have added the random class to swig so that you >>> can use this in python. >>> >>> 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 in any serious simulation >>> or publication, which is highly dependent on good random numbers. Some >>> information about the perfo
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 boost::mt19937,
which we could only "extern C{...}" into VOLK. I don't like that
architecturally, but I think it's definitely something I'd like to hear
Nathan's input on.
What I do like, however is the takeaway that,
"we can safely ignore the risk of overlapping subsequences"
for two parallelly running mt19937 sequences that were seeded
differently -- which means that we can well scale random number
generation to multiple cores, and especially lets us just divide each
output buffer into n_threads subbuffers and let the different generators
run parallely on that, without wrecking memory coherency bus bandwidth
too much. I guess that we'd ideally just spawn as many threads as there
are 4kB-pages to fill with random samples (meaning, at every 512
gr_complexes), just a wild guess.
Cheers,
Marcus
On 02.09.2015 16:35, Andre Puschmann wrote:
> 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] http://agner.org/random/
>
>
> On 02.09.2015 15:28, Marcus Müller wrote:
>> 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 the performance of boost's mt19937 + boost's
>> normal distribution variate, and basically, it's relatively slow,
>> indeed; generating 1e8 complex random numbers (meaning 200e8 random
>> floats) with a single thread takes
>>
>> g++ (GCC) 5.1.1 20150618 (x86_64)
>> test_rnd (Boost)
>> g++ -OXXX test_rnd.cpp
>> test_gr (gr::random)
>> g++ $(pkg-config --cflags --libs gnuradio-runtime) -OXXX te_gr.cpp
>> -O3 (optimized for speed)
>> 1.25 s
>> 5.92 s
>> -O0 (explicitly unoptimized) (default)
>> 23.62 s
>> 7.13 s
>>
>>
>> Someone who cares for speed could get a 5x increase of speed by using
>> boost, because that person would be using optimization, anyways.
>> However, I can't really explain what happens with boost and the
>> unoptimized case; it's really three times as bad as the current
>> implementation.
>> However, asking perf about this, the -O3 version spends nearly all of
>> its time in main(), whereas the -O0 spends most of it in some boost
>> functions -- which means that -O3 definitely inlines the calculations,
>> and from the disassembly alone I'd say all the stack operations needed
>> to jump in and out of routines seem to contribute significantly to the
>> problem.
>>
>> Of course, that's not really a benchmark for all systems. What about 32
>> bit? What about ARM? What about clang? Can anyone try to make a Windows
>> build?
>>
>> Best regards,
>> Marcus
>>
>> On 02.09.2015 14:10, Stefan Wunsch wrote:
>>> 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 algorithms. E.g. the period length is 1e8 compared to an
>>> up-to-date algorithm (Mersenne twister) with a period length of about
>>> 1e6000.
>>>
>>> I have fixed this [1] using boost.random and the mentioned Mersenne
>>> twister. Furthermore I have written some test-cases and fixed the
>>> transformation to Laplacian random numbers (the current implementation
>>> is wrong). As well, I have added the random class to swig so that you
>>> can use this in python.
>>>
>>> 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 in any serious simulation
>>> or publication, which is highly dependent on good random numbers. Some
>>> information about the performance is given on this page: [2]. Look for
>>> the generator mt19937 in table 24.5.
>>>
>>> Best regards
>>> Stefan
>>>
>>> [0] gnuradio/gnuradio-runtime/lib/math/random.cc
>>> [1] https://github.com/stwunsch/gnuradio/tree/newRandom
>>> [2]
>>> http://www.boost.org/doc/libs/1_59_0/doc/html/boost_random/reference.html
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> __
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 in any serious simulation > or publication, which is highly dependent on good random numbers. Some > information about the performance is given on this page: [2]. Look for > the generator mt19937 in table 24.5. Just a quick reminder that already, our noise source is known to be pretty slow, which prompted the fast_noise_source (which precaches some random data and reuses that). So, when you need maximum entropy, you use the slow one and if you just want some AWGN you use the fast one. Unless the load is significantly higher, I'd say we rather want better randomness than faster noise sources -- and the fast noise source will stay unaffected anyway. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 in portable C code.
> Point is though that our alternative in RNG seems to be boost::mt19937,
> which we could only "extern C{...}" into VOLK. I don't like that
> architecturally, but I think it's definitely something I'd like to hear
> Nathan's input on.
>
> What I do like, however is the takeaway that,
> "we can safely ignore the risk of overlapping subsequences"
> for two parallelly running mt19937 sequences that were seeded
> differently -- which means that we can well scale random number
> generation to multiple cores, and especially lets us just divide each
> output buffer into n_threads subbuffers and let the different generators
> run parallely on that, without wrecking memory coherency bus bandwidth
> too much. I guess that we'd ideally just spawn as many threads as there
> are 4kB-pages to fill with random samples (meaning, at every 512
> gr_complexes), just a wild guess.
>
> Cheers,
> Marcus
>
>
I agree with Martin here on the speed vs randomness. This is a noise source
that should primarily be used for simulations where it's OK to be rate
limited by your noise source (if you're biggest problem in life is being
rate limited by your noise source then I'm jealous). I'm a huge fan of
Agner Fog and his work is always great, but it uses C++ which can't be used
in VOLK kernels. If someone wants to port that to C and stick it in VOLK
I'd accept it.
Nathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 ways Stefan and I make normal distributed RV out of the uint32_t that this emits: >From getting "raw" uniform uint32_t instead of normal floats through boost's normal_distribution(rng) variate is that, to little surprise, 75% of time is spent looking up/interpolating/calculating based on the uniform integers to normally distributed floats. Blind guess is that this would be something that someone who really cares about speed might implement in VOLK with sufficient accuracy, making WGN generation X3x0-capable. Cheers, Marcus [1] let's say someone who wants to transmit at max has 4GB RAM to spare, or 2^29 gr_complexes, equal to ~2.6s of complex float noise [2] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/mt.pdf On 02.09.2015 18:53, Martin Braun wrote: > 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 in any serious simulation >> or publication, which is highly dependent on good random numbers. Some >> information about the performance is given on this page: [2]. Look for >> the generator mt19937 in table 24.5. > Just a quick reminder that already, our noise source is known to be > pretty slow, which prompted the fast_noise_source (which precaches some > random data and reuses that). So, when you need maximum entropy, you use > the slow one and if you just want some AWGN you use the fast one. Unless > the load is significantly higher, I'd say we rather want better > randomness than faster noise sources -- and the fast noise source will > stay unaffected anyway. > > M > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 that.
Regarding Boost's mt19937 and the ways Stefan and I make normal
distributed RV out of the uint32_t that this emits:
From getting "raw" uniform uint32_t instead of normal floats through
boost's normal_distribution(rng) variate is that, to little surprise,
75% of time is spent looking up/interpolating/calculating based on the
uniform integers to normally distributed floats. Blind guess is that
this would be something that someone who really cares about speed might
implement in VOLK with sufficient accuracy, making WGN generation
X3x0-capable.
Cheers,
Marcus
A call to SHA-256 can return 256 bytes at a timeMap those bytes
into {-1.0,1.0}. That may still not be fast enough, dunno. But the
distribution
should be good.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 doing his own "normalization" of the RV, and we use that.
Regarding Boost's mt19937 and the ways Stefan and I make normal
distributed RV out of the uint32_t that this emits:
From getting "raw" uniform uint32_t instead of normal floats through
boost's normal_distribution(rng) variate is that, to little surprise,
75% of time is spent looking up/interpolating/calculating based on the
uniform integers to normally distributed floats. Blind guess is that
this would be something that someone who really cares about speed might
implement in VOLK with sufficient accuracy, making WGN generation
X3x0-capable.
Cheers,
Marcus
A call to SHA-256 can return 256 bytes at a timeMap those
bytes into {-1.0,1.0}. That may still not be fast enough, dunno. But
the distribution
should be good.
Gah, that should be 256 *bits*, or 32 *bytes* at a time. Blame my
cats. They keep me awake at night. Yeah, that's it.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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, a paper relevant to SDR / GR / GRCon), please ping this list and the researcher/developer/presenter so that the info is searchable and might even be fixed in some future paper/presentation. All of the above said, hopefully Tom is reading through these emails & can respond.. Thanks for getting the discussion started! - MLD On Tue, Sep 1, 2015, at 09:40 AM, Jeon wrote: > In a presentation 'Stream Tags, PDUs, and Message Passing' by Tom > Rondeau, it seems some minor typos in pp. 14-18 > > Assuming my knowledge is correct, add_item_tag() should use offset of > output buffer, not input buffer. And get_tags_in_*() use offset of > input buffer. > > 1. Page 16 is referring nitems_read() for add_item_tag(). > 2. add_item_tag() slides contain figures of input buffer and >get_items_in_*() slides contain figures of output buffer. Since >I've not attended GRCon15 and judge a presentation without any >speech nor context, I might just point wrong thing. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[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 case),
the calculation of timestamp is done in such a way that appears to neglect a
decimation factor
in one of our blocks (keep_1_in_n). Details can be found below. Any
suggestions as to what's
going on or what to do about it would be most appreciated.
Sincerely,
Dan Marlow
Details:
OS: Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)
H/W: Ettus B210 with GPSDO,
Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 8GB memory USB3
gnuradio: 3.7.8
Flowgraph: This is provided to give an idea of what we are doing. It is
close to what we
are using, but not exact, since we edited the output
generated by GRC.
B210_2ch_filewriter.grc
Description: Binary data
The actual top_block we are running is attached below.
#!/usr/bin/env python2
##
# GNU Radio Python Flow Graph
# Title: Top Block
# Generated: Thu Jul 23 11:29:50 2015
##
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from optparse import OptionParser
import specest
import time
import pmt
from DAQ import rxcntl
class top_block(gr.top_block):
def __init__(self, fname1='raw1.dat', fname2='raw2.dat'):
gr.top_block.__init__(self, "Top Block")
##
# Extra Variables
##
self.fname1 = fname1
self.fname2 = fname2
self.nChannels = nChannels = 1
print "Entering top_block: fname1={0:s} fname2={1:s}".format(self.fname1,self.fname2)
##
# Variables
##
self.freq1 = freq1 = 142000
self.freq2 = freq2 = 142000
self.samp_rate = samp_rate = 1/4.
self.gain = gain = 60
self.N_average = N_average = 512
self.FFT_size = FFT_size = 32
self.BW = BW = 2000
self.BW = BW = 2500
##
# Blocks
##
self.uhd_usrp_source_0 = uhd.usrp_source(
",".join(("ser=F61177", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(self.nChannels),
),
)
self.uhd_usrp_source_0.set_subdev_spec("A:A A:B", 0)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(self.freq1, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.uhd_usrp_source_0.set_bandwidth(BW, 0)
#sensorNames = self.uhd_usrp_source_0.get_mboard_sensor_names(0)
#print "Sensor names=" + str(sensorNames)
GPStime = self.uhd_usrp_source_0.get_mboard_sensor("gps_time")
GPS_locked = self.uhd_usrp_source_0.get_mboard_sensor("gps_locked")
print "GPS Info: {0:s}; {1:s}".format(str(GPS_locked),str(GPStime))
self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()), uhd.ALL_MBOARDS)
if self.nChannels == 2 :
self.uhd_usrp_source_0.set_center_freq(self.freq2, 1)
self.uhd_usrp_source_0.set_gain(gain, 1)
self.uhd_usrp_source_0.set_bandwidth(BW, 1)
self.specest_moving_average_vff_0 = specest.moving_average_vff(N_average, FFT_size, 1, 4096)
self.fft_vxx_0 = fft.fft_vcc(FFT_size, True, (window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0 = blocks.vector_to_stream(gr.sizeof_float*1, FFT_size)
self.blocks_stream_to_vector_0 = blocks.stream_to_vector(gr.sizeof_gr_complex*1, FFT_size)
self.blocks_keep_one_in_n_0_0 = blocks.keep_one_in_n(gr.sizeof_float*FFT_size, N_average)
self.blocks_complex_to_mag_squared_0 = blocks.complex_to_mag_squared(FFT_size)
self.blocks_file_meta_sink_0 = blocks.file_meta_sink(gr.sizeof_float*1, self.fname1, self.samp_rate, \
1, blocks.GR_FILE_FLOAT, False, 100, self._extras(), False)
self.blocks_file_meta_sink_0.set_unbuffered(False)
if self.nChannels == 2 :
self.specest_moving_average_vff_1 = specest.moving_average_vff(N_average, FFT_size, 1, 4096)
self.fft_vxx_0_0 = fft.fft_vcc(FFT_size, True, (window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0_0 = blocks.vector_to_stream(gr.sizeof_float*1, FF
[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) was developed on the PC and the application was run on the B220. Now the PC is in the E310 itself: so the question in the subject comes natural (for us). What seems clear is that the code has to be cross-compiled for that on-board ARM processor (it is not clear where to download the corresponding SDK from the Ettus site but that is a different issue). But then it is not clear how to deal with GR (especially if you want to use GRC!) and how to deal with the output. For instance, suppose you just want to start with the FM receiver which is a sort of "Hello world!" of SDR, at least for us. Any suggestion is more than welcome. Maybe a helpful discussion might come out from our doubts which is useful also for others. Anyway TIA! BR, Maurizio. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 generate binaries for the E310; you can also do "small" compilations on the device itself, but we generally try to encourage people not to do that -- building something as big as whole GNU Radio would take overly long on the embedded processor of the E310. So, two aspects: If your flow graph doesn't use graphical sinks (ie. it works in the "no gui" build option), and only uses the blocks that GNU Radio comes with, you can just copy over the resulting python file to your E310 (e.g. via SCP), and run it there, unmodified. Especially if you already have experience with the B210, this is handy: Anything that works with the B210, and for which the E310's CPU is fast enough, should also work on the E310 (with very little restrictions). So you can design and test your flow graphs on your PC with the B210, and if they work and are fairly optimized, just copy them over to the E310. Now, if you need custom GNU Radio modules, and you need to build C++ GNU Radio blocks, you'll actually need to cross compile. [2] has a paragraph on building GNU Radio; do that, and also do the same (adjusting the path to the platform cmake file) with your OOTs, and you should be fine. Best regards, Marcus [1] http://files.ettus.com/e3xx_images/e3xx-release-3/ [2] http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk On 02.09.2015 23:46, Crozzoli Maurizio wrote: > > 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) was developed on the PC and the application was > run on the B220. Now the PC is in the E310 itself: so the question in > the subject comes natural (for us). > > > > What seems clear is that the code has to be cross-compiled for that > on-board ARM processor (it is not clear where to download the > corresponding SDK from the Ettus site but that is a different issue). > But then it is not clear how to deal with GR (especially if you want > to use GRC!) and how to deal with the output. For instance, suppose > you just want to start with the FM receiver which is a sort of “Hello > world!” of SDR, at least for us. > > > > Any suggestion is more than welcome. Maybe a helpful discussion might > come out from our doubts which is useful also for others. > > > > Anyway TIA! > > > > BR, > > Maurizio. > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > /This e-mail and any attachments// is //confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please delete > this message and any attachments and advise the sender by return > e-mail, Thanks./ > > *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se > non è necessario.* > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 absolute number of items written to each output buffer. For rate-changing blocks, the input/output offsets will be different. In add_item_tag(), you specify an output port, so that's another reason to think in terms of output samples. Yes, get_items_in_*() fetch tags from a stream on an input port. Again, offsets are absolute, so input buffers are not really relevant. But, it makes sense to search for tags related to the samples in the input buffer. The easiest function to use is get_tags_in_window(), which simply adds nitems_read[port] to the provided offsets. The absolute offset is available as a field in each tag. The get_tags_in_range() function does the same thing, just without adding nitems_read[port]. You could search for tags whose offsets are earlier/later than the offsets of the samples in an input buffer. However, older tags are likely to have been deleted, and future tags (I think this can actually happen) would be really confusing. - Jeff On 09/02/2015 01:50 PM, Michael Dickens wrote: 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, a paper relevant to SDR / GR / GRCon), please ping this list and the researcher/developer/presenter so that the info is searchable and might even be fixed in some future paper/presentation. All of the above said, hopefully Tom is reading through these emails & can respond.. Thanks for getting the discussion started! - MLD On Tue, Sep 1, 2015, at 09:40 AM, Jeon wrote: In a presentation 'Stream Tags, PDUs, and Message Passing' by Tom Rondeau, it seems some minor typos in pp. 14-18 Assuming my knowledge is correct, add_item_tag() should use offset of output buffer, not input buffer. And get_tags_in_*() use offset of input buffer. 1. Page 16 is referring nitems_read() for add_item_tag(). 2. add_item_tag() slides contain figures of input buffer and get_items_in_*() slides contain figures of output buffer. Since I've not attended GRCon15 and judge a presentation without any speech nor context, I might just point wrong thing. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 transmitting flow graph in GNU radio with USRP ? If yes, could you please give any hint ? Thank you and best regard Hoang On Mon, Aug 31, 2015 at 7:31 PM, Hoang Nguyen Tran wrote: > Thank you Rich, > I have added Rational Resample with the formular : Fs_out = Fs_in x > Interpolation / Decimation > Then the grc run without error. > > > On Fri, Aug 28, 2015 at 7:03 PM, Richard Bell > wrote: > >> Hi Hoang, >> >> Yes it's a problem with your design. You have 2 Msps feeding into an >> audio sink that probably goes up to 48 ksps. You need to change your sample >> rate from 2 Msps to a rate your sound card supports. I would target one of >> the default rates you can select from the audio sink. You can use polyphase >> arbitrary resampler block with the proper resampling ratio 2M/48k entered >> leaving the taps blank and the other parameters to default. >> >> Hope that helps, >> Rich >> >> On Fri, Aug 28, 2015 at 2:19 PM, Hoang Nguyen Tran >> wrote: >> >>> Dear all, >>> >>> I have just built a FSK receiver aim to receive Cubesat data with FSK >>> modulation with 9600 baud rate, below is my flow graph. >>> I have just tested it with usb dongle RTL-SDR, however when I'm using >>> audio sink, I received O (overrun I think) continuously . >>> Does it have anything wrong with my set up ? >>> >>> samplerate 2M >>> cut off freq 9600 >>> transition 4800 >>> >>> I really appriciate for any comment on my FSK receiver flowgraph, I am a >>> newbie :) >>> >>> Thank you and best regard, >>> Hoang >>> >>> -- >>> -HoangNT- >>> PhoneNo : +841654248782 >>> Skype : hoangastro >>> FB : https://www.facebook.com/kenshin.rorouni >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> > > > -- > -HoangNT- > PhoneNo : +841654248782 > Skype : hoangastro > FB : https://www.facebook.com/kenshin.rorouni > -- -HoangNT- PhoneNo : +841654248782 Skype : hoangastro FB : https://www.facebook.com/kenshin.rorouni ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to add a new block
I am getting lots of error in basic square block itself. so please give me a step by step procedure to add a new block. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to add a new block
Dear Bala, I'd like to know what lots of errors in basic square block are. Anyway, if you want to add a new block, please refer: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules and gr_modtool in http://static1.squarespace.com/static/543ae9afe4b0c3b808d72acd/t/55dc8a33e4b0ab4821199b21/1440516659004/5.+braun_martin-GR_from_Scratch+2015-08-24.pdf Regards, Jeon. 2015-09-03 15:06 GMT+09:00 Bala V. : > I am getting lots of error in basic square block itself. so please give > me a step by step procedure to add a new block. > > -- > Posted via http://www.ruby-forum.com/. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
