Re: [Discuss-gnuradio] Bug in

2015-09-27 Thread marco Ribero
Sorry, it was my fault. I've only looked generic implementation, without pay attention that is the operator * is also defined for complex. Have a good day Il giorno sab 26 set 2015 alle ore 23:35 Marcus Müller < marcus.muel...@ettus.com> ha scritto: > Hi Marco, > > volk_32fc_x2_multiply_32fc is

[Discuss-gnuradio] Bug in

2015-09-26 Thread marco Ribero
seems a normal pair of float multiplication. Is it a bug or a feature? Thanks, Marco Ribero ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Install UHD after GNURadio installation

2015-07-03 Thread marco Ribero
> Radio, so it's simply a good idea to update GNU Radio, rebuild it in whole > (if you've got more than 4GB of RAM and more than one CPU core, try "make > -j ") and re-install it. You'll also have to re-compile > every OOT module (eg. gr-osmosdr). > > Best

[Discuss-gnuradio] Install UHD after GNURadio installation

2015-07-01 Thread marco Ribero
Hi, now I need to install also the UHD module of gnuradio(before I've used only RTL). Is possible to install this module without reinstall the entire gnuradio? I've tried the easiest apprach, mkdir/cmake/make.. in gnuradio/gr-uhd, but it doesn't work. Thanks, marco

Re: [Discuss-gnuradio] Choose thread

2015-05-27 Thread marco Ribero
Il giorno mer 27 mag 2015 alle ore 16:29 Marcus Müller < marcus.muel...@ettus.com> ha scritto: > Yes. The Thread-per-Block-scheduler gets its name from the fact that > every block gets its own thread. > You should really use it -- using STS will probably kill the performance > you can gain by acce

Re: [Discuss-gnuradio] Choose thread

2015-05-27 Thread marco Ribero
Il giorno dom 24 mag 2015 alle ore 19:52 Tom Rondeau ha scritto: > Don't use the STS scheduler. It is, after all, the Single-Threaded > Scheduler. And setting the thread affinity under that condition is a nop. > That will only work with the default TPB scheduler. > > Tom > > I need that different

[Discuss-gnuradio] Basic theory of IIR filters

2015-05-22 Thread marco Ribero
t both approaches(parallel and cascade) require only the previous output,I think what the implementaion would be not difficult: thanks to the expansion of recurrence expression, is "sufficient" something like a parallel sum prefix. Thanks, Marco Ribero _

[Discuss-gnuradio] Choose thread

2015-05-22 Thread marco Ribero
Hi, I've a question about thread management..I like the fact that scheduler can launch blocks in different threads, but I'd like to execute some blocks inside the same thread(CUDA require to perform all operations from a single thread)..for the moment I'm using GR_SCHEDULED=STS,but it blocks at all

Re: [Discuss-gnuradio] Which blocks do you like?

2015-05-20 Thread marco Ribero
Thank you for your replies!! I really appreciate them. If you want to give a look about my porting,here is possible to see something: https://github.com/m-ri/gr-CUDA Greetings, marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lis

Re: [Discuss-gnuradio] Which blocks do you like?

2015-05-18 Thread marco Ribero
For the bug, wouldn't be sufficient to substiture the above code // Find the magnitude squared of the correlation std::vector corr_mag(noutput_items); volk_32fc_magnitude_squared_32f(&corr_mag[0], corr, noutput_items); with: std::vector corr_mag(noutput_items+1); volk_32

Re: [Discuss-gnuradio] Which blocks do you like?

2015-05-17 Thread marco Ribero
_mag[i+1]) i++; is not possible that the variable i will go outside the array corr_mag?I know that is necessary a strange pattern in order to have the last item greater than the previous.. Greetings, marco ribero ___ Discuss-gnuradio

[Discuss-gnuradio] Which blocks do you like?

2015-05-15 Thread marco Ribero
Hi, for my thesis I'm making "porting" of gnuradio blocks over CUDA.. For the moment,I've bring basick blocks,FIR filter,FFT,an FM receiver(not so good due to latency) and I'm working with ofdm..I still need to implement IIR filter Which other blocks do you think that could be nice(useful,get perf

Re: [Discuss-gnuradio] How make a *.t block

2015-05-06 Thread marco Ribero
Tahnk you very much for your reply. I've tried different time with templates,but I was not able to obtain a result(cmake and make finish errors,but I suppose that swig crash,because python scripts are not able to access to any block written in C,also blocks without template).. At the end I've solv

[Discuss-gnuradio] How make a *.t block

2015-05-05 Thread marco Ribero
Looking inside gnuradio,I've found blocks like divide_XX where relative files have an extension .t (like divide_XX_impl.cc.t )..in this way,is possible to manage different types for the same block. How is posssible to create blocks like them? is necessary to use particular parameters in gr_modtools

Re: [Discuss-gnuradio] Message passing(connect) in C++

2015-04-30 Thread marco Ribero
Marcus, thank you very much for your deep answer. Your proposal about the usage of your_block::detail()->input(0)->buffer()->link seem very interesting, so I shoulld evaluate if use this mechanism or only some memory allocation created with malloc. I'd prefer to simplify the life of user as much a

Re: [Discuss-gnuradio] Curiosity about implementation of block with multiple data type

2015-04-30 Thread marco Ribero
Ok I've understood. Thank you for your answer. Have a good day, Marco Il giorno gio 30 apr 2015 16:47 Tom Rondeau ha scritto: > On Thu, Apr 30, 2015 at 9:30 AM, marco Ribero > wrote: > >> Looking better about implementation of blocks like fft,fir,etc a question >> r

[Discuss-gnuradio] Curiosity about implementation of block with multiple data type

2015-04-30 Thread marco Ribero
Looking better about implementation of blocks like fft,fir,etc a question rise in my brain. Why in blocks with selectable input/output data type there are C++ multiple file, each one with the specialization of a single data type(file finishing with _cc,_ff,etc), instead of use template(and eventual

Re: [Discuss-gnuradio] Message passing(connect) in C++

2015-04-30 Thread marco Ribero
>> I prefer to change your topology to refuse the need you've mentioned. >> Otherwise describe your problem with more details. >> >> >> Best, >> Mostafa >> >> >> >> On Thu, Apr 30, 2015 at 3:43 PM, marco Ribero >> wrote: >>

[Discuss-gnuradio] Message passing(connect) in C++

2015-04-30 Thread marco Ribero
Hi all, I have another question. How can I connect the input and output port of different blocks,from inside a C++ block? In the documentation I've only seen the msg_connect() for python Thanks, marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gn

Re: [Discuss-gnuradio] CMake and CUDA

2015-04-23 Thread marco Ribero
27; object has no attribute 'mod_ff' Reattached kernel driver Thanks for your effort, marco Il giorno mar 21 apr 2015 alle ore 16:37 Tom Rondeau ha scritto: > On Mon, Apr 20, 2015 at 1:42 PM, marco Ribero > wrote: > >> I try to give more details. >> In order to create b

Re: [Discuss-gnuradio] Bidirectional communication between attached blocks

2015-04-20 Thread marco Ribero
Il giorno lun 20 apr 2015 alle ore 16:30 Tom Rondeau ha scritto: > >> > We've never been hot on the idea of using VOLK for GPU stuff. VOLK kernels > tend to do one thing at a time and don't worry about data movement (too > much) because the SIMD registers are right there. Going to GPUs takes a lo

Re: [Discuss-gnuradio] CMake and CUDA

2015-04-20 Thread marco Ribero
I try to give more details. In order to create blocks using the standard way(cmake/make/install) with Cuda,I've modified the CMakeList in /lib as shown before. My block is created using gr_modtool and the language is c++. The fact is that "make test" works well,while in GnuRadio interface give me t

Re: [Discuss-gnuradio] Bidirectional communication between attached blocks

2015-04-20 Thread marco Ribero
ock, you can for example first > construct your cuda block, and then give your "downstream" block the > pointer to that in its constructor. > > To the user, this will look like one block, though there are two (or more) > inside. > > Greetings, > Marcus > > >

Re: [Discuss-gnuradio] Bidirectional communication between attached blocks

2015-04-20 Thread marco Ribero
Thank you very much. Your solution is much cleaner. Have a good day, Marco Il giorno lun 20 apr 2015 alle ore 09:29 Marcus Müller < marcus.muel...@ettus.com> ha scritto: > Hi marco, > > what you describe as ID already exist: every block has a function alias(), > giving it a string "name", which

[Discuss-gnuradio] Bidirectional communication between attached blocks

2015-04-19 Thread marco Ribero
Hi all, I'd like to establish a bidirectional communication between two attached blocks, without asking the user to write code like msg_connect(). One way could be: the upstream block generate an id like ID=typeBlock+pseudorandomNumber and send it to the next block using a tag. After what the upst

[Discuss-gnuradio] CMake and CUDA

2015-04-19 Thread marco Ribero
Hi all, I'm playing with CUDA and GNURadio. For the moment I've used separatly nvcc in order to compile device code: I've tried different tutorials which explain how to use CUDA with CMake, but I was not able to obtain a good result. Can someone explain me how to modify Cmake's file of a basic GNU