Re: Passing real data from a thread to the next block

[Martin Lülf]

Dear Isaac,

you can overwrite the start method of gr::block 
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f


This function will be called once the processing starts.

Yours
Martin


On 2020-11-18 02:35, isaac mario tupac davila wrote:

Hi Marcus

Thanks for your answer. I am restructuring the design of my OOT block.

I'd like to ask a last question about it...I am trying to send some 
commands (array of bytes) to an external hardware only ONCE before 
starting with my real time data acquisition . The problem is that if I 
implement the sending of the commands in the general work of my block, 
the commands will be sent each time the general work finishes and starts 
again. My solution proposed is to begin the execution of my flowgraph 
and send an external signal (specificallykill -SIGIO PID) from terminal 
to call the implemented method which sends the commands, so that my 
general work will only focus on the data acquisition and I will send the 
commands only once.


My question is: Is there a facility or tool that GNU Radio gives me to 
solve this situation? There should be a more suitable solution.


Any help or recommendation would be appreciated.
Thanks

Regards
Isaac.



El dom., 15 nov. 2020 a las 13:50, Marcus Müller (>) escribió:


Hello,

On 15.11.20 06:26, isaac mario tupac davila wrote:
 > Hello
 >
 > I'm Isaac.

Hi Isaac, nice having you.

 > I have a question about threads. I've created three
 > threads and I want to pass real data from one thread to the next
block
 > directly without returning to the general work method.

That sounds like a misguided design approach. Please don't do that.

The work function is meant to be seen as atomically processing a bit of
data from its input to its output.

If you need asynchronous messaging, then use the msg_passing facilities.
These make sure you don't change the state of the block while its
general_work is executing.

 > I could give
 > value to the out array in the thread but for some reason the data
 > doesn't pass to the next block. I am not sure if it's because I
didn't
 > put: return noutput_items in the thread,

What you describe as thread makes no sense – the way GNU Radio is,
there's exactly one thread executing a block's general_work at a time,
and that's the thread of the block_executor. And `return` ends that
execution; that's how C++ works.

 > as normally this is in the
 > general work method... I also add that the function is defined in the
 > thread as void*function and I defined the out array as a
complex*.
 >
 > Any help would be appreciated.

I'm afraid there's something not GNU Radio-compatible in the way you've
architected your system, but we sadly don't know your system well enough
to comment on what to change.

Best regards,
Marcus

Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks

[Martin Lülf]

Dear Tom,

thanks for your reply.

I created an account on the gnuradio.org platform. A day later the 
account is still disabled, so I assume there is a manual confirmation 
required.


So I kindly ask somebody on the list with the right permissions to 
activate my account "MartinLuelf" with the same Email address as I use 
for this mailing list.


Thank you and have a nice weekend eveybody.
Martin

On 03/04/16 18:05, Tom Rondeau wrote:

On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf > wrote:

Dear mailing list,

we are trying to create a status overview of our receiver by using
the control ports feature. For most of our custom made blocks this
works very well and we can see the exported variables.

But for a few blocks the exported variables do not show up in the
control port monitor. After putting tracing lines in these blocks we
found out that the setup_rpc function is not called. The only
difference we could see between the blocks were the setup_rpc
function is called and the ones where it is not is that the latter
have no stream in- or output. Instead they only use the message
passing API to process data, like the mesage debug block from GNURadio.

A minimal working example of a block whichs setup_rpc() method is
not called can be found at http://pastebin.com/cBFJCnW7 with private
and public header files at http://pastebin.com/35WhFqQ0 and
http://pastebin.com/zb4jBRAw

If we run this block and feed messages to it, we get the following
output:
constructor()
ControlPort Monitor running.
INFO: Apache Thrift: -h localhost -p 40444
monitor::endpoints() = -h localhost -p 40444
process frame()
process frame()
[...]
process frame()
process frame()
running: ['gr-ctrlport-monitor', 'localhost', '40444']
process frame()
process frame()
[...]
process frame()
process frame()

We would expect to see an additional line at the beginning saying
"setup_rpc()" (see line 71 of the c++ code) and consequently see the
variable "testval" in the control port monitor, like it does for our
working blocks.

The above output is generated with GNURadio version
3.7.8.1-229-g51c0426a manually compiled from source on an Ubuntu
trusty system (64 bit).

The only difference we could find between the blocks working as
expected and the ones that do not, is that they use streaming for
data transport, i.e. that their work or general_work function has
some actual data processing and their gr::io_signature is not set to
(0,0,0).

I kindly ask for your help to find out why the setup_rpc function is
not called for our example block posted above and what we can do to
change this.

Yours sincerely
Martin Luelf


Martin,

This definitely sounds like a bug for a case that wasn't planned for
initially. Can you open up a bug report with this information on our
Issue tracker on gnuradio.org ?

Thanks,
Tom



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help: Feedback causing Flow graph loops

[Martin Lülf]

Hi,

since I also had trouble with this issue at first, please allow me to 
clarify this further: GNURadio does not support looping of blocks. 
Inside a single block you can loop as often as you wish and that is 
exactly how the available PLLs in GNURadio are made. Just search the 
mailing list for more details, since this topic has been discussed a 
couple of times already.


Yours
Martin



Am 09.08.2013 17:17, schrieb Martin Braun (CEL):

On Fri, Aug 09, 2013 at 07:31:58AM -0700, tom sutherland wrote:

I am trying to make a simple PLL using a VCO but I get an error
RuntimeError:flow graph has loops!. Anyway around that?


Nope, stock GNU Radio does not support loops. There's plenty of PLLs
available already, though.

MB



___
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] linking Gnuradio and Gpredict ?

[Martin Lülf]

Hi,

Gpredict is based on predict, which has several interfaces for Doppler 
prediction. Not sure if Gpredict inherited these interfaces.


Yours
Martin


Am 22.07.2013 13:31, schrieb M Dammer:

Is it possible to link Gnuradio and Gpredict ? I want to use Gpredict as
tracker controlling the antenna position and to pass doppler corrected
frequency data to Gnuradio.
Does any interface to Gpredict (or hamlib) exist ?
thanks for any hints, Mark



___
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] digital_ofdm_cyclic_prefixer::work

[Martin Lülf]

Hi,

it looks like the block inherits from gr_tagged_stream_block which will 
will call a blocks work function with the exact number of samples for 
one PDU with a known size in general_work and will call consume for you 
afterwards.


http://gnuradio.org/doc/doxygen/classgr__tagged__stream__block.html#ac8934fdb1cb2816f2eed20287314614d

Yours
Martin


Am 29.06.2013 08:15, schrieb Stefano:

Hi all,

please can someone tell me why that work method ( like others in the
digital_odfm_xx ) does not call consume_each (n) or consume ( i,n ) ?

many thanks,
Stefano

___
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] build-gnuradio statistics

[Martin Lülf]

Hi,

I would solve this with a small PHP Script on the webserver (or whatever 
scripting language is available on the webserver). The script can 
evaluate the called URL including parameters.


So in the build gnuradio script you would call something like this
wget http://example.com/script.php?param1=5param2=pi

The Script on the webserver will now have access to param1 and param2 
and can store them in a Database, or whatever you would like to do and 
can return (echo) a few charakters (e.g. 1 ok, 0 malformed parameter).


This way the build gnuradio script can then evaluate the content of the 
downloaded file to see if anything went wrong.


For this to work you only need HTTP access to the script webserver on 
the install PC. Many PCs are behind Firewalls that drop traffic on Port 
25 if you try to use Email, but port 80 is almost always oppen.


I also agree with Jonathan, that sending back feedback should be a 
opt-in decision during the installation.


Yours
Martin

Am 28.05.2013 18:30, schrieb Johnathan Corgan:

On Tue, May 28, 2013 at 9:14 AM, Marcus D. Leech mle...@ripnet.com
mailto:mle...@ripnet.com wrote:

I'd like some suggestions about automating uploading of this
one-liner of stats data to some website somewhere so that I can
review it.
   Maybe something we can turn on on the gnuradio.org
http://gnuradio.org website?


You could ask in the script if the user wants to send feedback via email
or not, with the default set to no.  Otherwise, any automated system
would likely be negatively perceived.

That said, I could see having an email processing bot on gnuradio.org
http://gnuradio.org turn received emails into a statistics page, said
bot being written by you of course :)

--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.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

Re: [Discuss-gnuradio] Build error

[Martin Lülf]

Hi Les,

try to build with verbose output enabled, to see if there might be more 
errors/warnings. If I remember correctly you need to run something like 
this:

make VERBOSE=1
If it does not work, search the list/website on how to turn verbose 
building on.


Yours
Martin

PS: Please make sure you answer to the list and not to an individual 
person. This way everyone on the list can help you and it is archived 
fur future reference, if someone has the same problem.



Am 05.05.2013 07:47, schrieb Les Barker:

Hi Martin

Thanks for the reply

I had the same thought, that it was only an error message, BUT the
computer appears to go into a loop after that message and after more
than 24 hours the build has not progressed any further.
Must I just leave it to carry on, or could there be some other problem
that I am not aware of?

I really appreciate your help as I am into an area of which I have very
little knowledge, but a lot of interest.

Regards
Les


- Original Message - From: Martin Lülf m...@mluelf.de
To: discuss-gnuradio@gnu.org
Sent: Saturday, May 04, 2013 2:44 PM
Subject: Re: [Discuss-gnuradio] Build error


Am 04.05.2013 14:32, schrieb Les Barker:

Hi All
I turn to this discussion group in the hopes that someone can help! I am
trying to build gnuradio on the way to achieving a working GQRX SDR
program.
I have tried various releases of gnuradio, including the latest,
gnuradio-3.6.4.1, all with the same result i.e.
[ 40%] Building CXX object
gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o


/home/les/sdr/gnuradio-3.6.4.1/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:

In function ˜void init_gnuradio_core_general():

/home/les/sdr/gnuradio-3.6.4.1/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:323844:21:

warning: variable md set but not used [-Wunused-but-set-variable]

I am using Ubuntu 12.04 on a 32 bit Pentium 3 desktop PC.

I am new to Linux and definitely not a proficient programmer, just a
radio ham who would like to use Gqrx SDR.

Does anyone have a solution to the problem?

Thanks

Les ZS2VA


Hi Les,

the lines you posted are compiler warnings, but not errors. That means
that the build process should run through without trouble, or there is a
real error further down the line.

These compiler warnings are there to notify you about possible (logic)
mistakes in the code, but since they occur in the SWIG generated
(PYTHON_wrap.cxx) code I suppose it will be very hard to fix them, so
just ignore them.

Yours
Martin

___
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] Build error

[Martin Lülf]

Am 04.05.2013 14:32, schrieb Les Barker:

Hi All
I turn to this discussion group in the hopes that someone can help! I am
trying to build gnuradio on the way to achieving a working GQRX SDR program.
I have tried various releases of gnuradio, including the latest,
gnuradio-3.6.4.1, all with the same result i.e.
[ 40%] Building CXX object
gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o

/home/les/sdr/gnuradio-3.6.4.1/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:
In function ˜void init_gnuradio_core_general():

/home/les/sdr/gnuradio-3.6.4.1/build/gnuradio-core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:323844:21:
warning: variable md set but not used [-Wunused-but-set-variable]

I am using Ubuntu 12.04 on a 32 bit Pentium 3 desktop PC.

I am new to Linux and definitely not a proficient programmer, just a
radio ham who would like to use Gqrx SDR.

Does anyone have a solution to the problem?

Thanks

Les ZS2VA


Hi Les,

the lines you posted are compiler warnings, but not errors. That means 
that the build process should run through without trouble, or there is a 
real error further down the line.


These compiler warnings are there to notify you about possible (logic) 
mistakes in the code, but since they occur in the SWIG generated 
(PYTHON_wrap.cxx) code I suppose it will be very hard to fix them, so 
just ignore them.


Yours
Martin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble posting messages to block's message port

[Martin Lülf]

I had this issue once and if I remember correctly, connecting the block 
to the flowgraph (i.e. connect any block to your message port, even if 
that port will never send messages) will make your message handler react 
to messages from your python code.


Hope this helps
Martin


Am 03.05.2013 19:46, schrieb Sean Nowlan:

On 05/03/2013 01:41 PM, Sean Nowlan wrote:

On 05/03/2013 01:26 PM, Marcus Müller wrote:

Hi Sean,
have you tried using tb.msg_connect(src, out_port_id, dst,
in_port_id) instead of tb.connect?

Cheers
Marcus


I'm trying to post a message to a port from top_block as opposed to
connecting the output port of one block to the input of dst. The
documentation indicates this can be done using
dst.to_basic_block()._post(port, msg).Unfortunately this is not
working for me.

http://gnuradio.org/doc/doxygen/page_msg_passing.html


More precisely, posting the message doesn't fail, so I *guess* it
worked. However the handler function is not called. I used the
boost::bind call to bind the message handler function following the lead
of the example code.

--sean



___
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] Usage of Message Queues

[Martin Lülf]

Am 23.02.2013 17:09, schrieb Hanz:

Thank you much for your answer. Indeed, its a shared pointer. I now figured
out, the the only way to get the data is via .to_string().




So my thought was, that all the messages then should contain one byte (with
one bit information). At the end, my code looks like that:

tb = top_block()
tb.start()

while 1:

point=tb.sink_queue.delete_head()
point=point.to_string()
print len(point)

The first curiosity is, that the length variates from 2 up to 2048. Can
somebody explain why? The next question is, how to i convert the bitvalue
of the string to an actual char?



Hi,

your code setup with the blocks and connects looks fine to me.

Although I have not checked the details of msg_sink I would expect it to 
process blocks of incomming bytes into messages. So a message can 
contain an abritrary amount of bytes in it (I think that is why your 
length varies). Once again speaking for the C++ interface with the 
method length() you will get the number of elements that this message 
contains. Then you can usually access the message's data through a call 
to the msg() function which returns a pointer to a byte array containing 
the bytes. This will be wrapped to some python code, so check the return 
type of msg() and try to process this returned data instead of 
to_string() if you are interested in the data itself. So I think your 
code should look something like this (not tested, please check agains 
the actual Python interface documented with Sphinx or Python docstrings):


message=tb.sink_queue.delete_head()
data=message.msg()
length=message.length()

for i in xrange(length) :
byte=data[i]

Hope this gives you an idea on how to use the interface.

Martin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Detecting EOF of previous block

[Martin Lülf]

Hi Martin,

your suggested solution of dynamically resetting multiple_output was 
indeed a very good hint. With this I was able to terminate my block 
without interrupting from the outside. Thank you!


However a problem that I still have is that the last pieces of data get 
dropped if there are not enough to form a full output_multiple (as you 
already suggested in your mail). As these last bits still contain 
valuable information I somehow still need to process them. In order to 
do so I would like to detect the upcoming end in my block so that I can 
pad my input with enough zeros to retrieve a full output block instead 
of cutting away the end.
Since a few additional outputs don't hurt my application right now I add 
a trailing zero sequence at my source, however this causes some problems 
with unit testing as I can't predict the number of trailing zero blocks 
that might additionally be generated at the output.


So my question is: Can I make gnuradio to not drop the last bits if 
there are less items left than necessary to create output_multiple items 
but instead present this few items to my block together with the 
information that these are not as much items as expected for a full block?


Yours
Martin


On 02/14/2013 02:51 PM, Martin Braun (CEL) wrote:

Hi Martin,

this won't 100% answer your Q's, but perhaps it'll help:

On Thu, Feb 14, 2013 at 02:37:43PM +0100, Martin Lülf wrote:

Dear list,

I have another question regarding stopping the flowgraph. This time it is
about streaming blocks, no messages involved at all.

My flowgraph looks like this  (block A) --byte--  (block B) --byte--  ...

Block A is a byte source that signals EOF at a certain point, lets assume
after sending out 11 bytes.

Block B is a ratio 1:1 sync block which works on groups of input items,
say 5 bytes. If B's work is provided with less than 5 samples it will
return 0 and wait to get more samples.


We do this a lot in the experimental OFDM branch; an easy example might
be the CRC block:
https://github.com/benreynwar/gnuradio/blob/ofdm/gr-digital/lib/digital_crc32_bb.cc


Unfortunatley the blocksize of block B is not fixed but based on a state,
so I can't call set_output_multiple to tell the scheduler to only provide
me with multiples of 5 bytes because a few items later it might change to
6 bytes.


You *can* call set_output_multiple() from within work(). Remember to
re-set it.


As you can see from the example above B will process the first 10 bytes
like expected, but then there is still one byte left to be processed by B.
The problem I have is to detect whether block B is asked to process only
one byte, because that's all the scheduler has so far (but A will produce
more), or if it is asked to process this one sample because that is the
last one available (A has already signaled EOF).

Is there any build in way to detect that the previous block in the
flowgraph has already signaled EOF? The only way I could think of is to
attach an EOF stream tag to the stream in the previous block A and
evaluate the tags in block B. Are there any other approaches/ideas? Might
a general EOF tag be a good idea for gnuradio (so that file source and
head or even the scheduler itself attach the EOF tag)?


My guess is stream tags are the easiest solution. If you're saving state
anyway in your downstream block, you might as well add another case for
the final block, i.e. a tag that says here's 3 items, and there won't
be any more.

In most cases, a dedicated EOF tag wouldn't be useful, though. When a
file source hits EOF, it usually shuts down the flow graph by returning
-1, and the downstream blocks eventually stop, too.
This might even be enough in your case; if you use set_output_multiple()
in work, there is still something (but not enough) in the input buffer
for your block B, and you don't really need to process that (because
it's just a dangling byte), perhaps this is all you need.

MB



___
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] Segmentation fault for aligned volk kernel with custom arrays

[Martin Lülf]

 On Fri, Nov 9, 2012 at 11:47 AM, Martin Lülf m...@mluelf.de wrote:
 Hi list,

 I am trying to speed up my own gnuradio block using volk. Besides using
 volk on gnuradios input and output buffers I also want do use it with my
 own arrays. I found this Thread in the mailing list archive
 http://lists.gnu.org/archive/html/discuss-gnuradio/2012-09/msg00055.html
 which shows how to allocate aligned memory and I also tried using
 posix_memalign directly as well (see the code below). Both end in the
 same
 result: If I run my block with the aligned volk_32fc_x2_multiply_32fc_a
 kernel my application crashes with a Segmentation fault. I checked with
 a
 debugger and it is the volk call at which the segfault happens. I get no
 segfaults for the unaligned version volk_32fc_x2_multiply_32fc_u. My
 flowgraph is created with grc and just contains of
 signal_source-my_block-null_source

 Running volk_profile, sse3 is selected for both kernels (and the aligned
 version does not segfault here), so there has to be an issue with my
 code.

 I am working on an Intel Xeon X5690 CPU with an 3.2.0-32-generic
 #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64
 GNU/Linux
 and gnuradio-3.6.0

 I know that there is a newer version of gnuradio available but before
 turning my whole system upside-down I'd like to know if there is
 anything
 wrong with the minimal code example below.

 Any help is appreciated.
 Yours
 Martin

 Martin,

 The problem is in your constructor. You have not told the block to
 work with your alignment. In blocks that use VOLK, we have this in the
 constructor:

   const int alignment_multiple =
   volk_get_alignment() / sizeof(gr_complex);
   set_alignment(std::max(1, alignment_multiple));

 We divide the alignment by sizeof(output type) specifically. We should
 be able to hide this in the future, but there's some uncertainty as to
 whether the output type is always the right answer if there are
 multiple types defined, so we do the right thing for each block.

 Also, a general note on using fftwf_malloc that I found out the hard
 way. If you have an AVX processor and want to use AVX kernels, FFTW
 needs to be build using --enable-avx. I've had to build FFTW by hand
 on my AVX processors where I want to use VOLK.

 Tom



Hi Tom,

thank you very much for your help. Adding the few lines to my constructor
solved the segfault problem. Now I am trying to understand what I did :)

I assumed with calling set_alignment I tell the scheduler on which bounds
he should try to align, which will result in more aligned arrays being
passed to work. However even without telling the scheduler which alignment
I would like to have is_unaligned() should never return false, when the my
input or output arrays are unaligned and thus in the worst case the
unaligned kernel is called, although the arrays are indeed aligned, but
not the other way around. What am I missing here?

Yours
Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Segmentation fault for aligned volk kernel with custom arrays

[Martin Lülf]

Hi list,

I am trying to speed up my own gnuradio block using volk. Besides using
volk on gnuradios input and output buffers I also want do use it with my
own arrays. I found this Thread in the mailing list archive
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-09/msg00055.html
which shows how to allocate aligned memory and I also tried using
posix_memalign directly as well (see the code below). Both end in the same
result: If I run my block with the aligned volk_32fc_x2_multiply_32fc_a
kernel my application crashes with a Segmentation fault. I checked with a
debugger and it is the volk call at which the segfault happens. I get no
segfaults for the unaligned version volk_32fc_x2_multiply_32fc_u. My
flowgraph is created with grc and just contains of
signal_source-my_block-null_source

Running volk_profile, sse3 is selected for both kernels (and the aligned
version does not segfault here), so there has to be an issue with my code.

I am working on an Intel Xeon X5690 CPU with an 3.2.0-32-generic
#51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
and gnuradio-3.6.0

I know that there is a newer version of gnuradio available but before
turning my whole system upside-down I'd like to know if there is anything
wrong with the minimal code example below.

Any help is appreciated.
Yours
Martin


---
#ifdef HAVE_CONFIG_H
#include config.h
#endif

#include ccsds_fll_cc.h
#include gr_io_signature.h
#include volk/volk.h
#include stdio.h
#include cstdlib
#include fftw3.h

ccsds_fll_cc_sptr
ccsds_make_fll_cc ()
{
return ccsds_fll_cc_sptr (new ccsds_fll_cc ());
}

ccsds_fll_cc::ccsds_fll_cc ()
  : gr_block (ccsds_fll_cc,
gr_make_io_signature (1, 1, sizeof (gr_complex)),
gr_make_io_signature (1, 1, sizeof (gr_complex)))
{
// nothing
}

ccsds_fll_cc::~ccsds_fll_cc ()
{
// nothing
}
int  ccsds_fll_cc::general_work (int noutput_items,
gr_vector_int   ninput_items,
gr_vector_const_void_star   input_items,
gr_vector_void_star output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];

unsigned int num = (noutput_items  ninput_items[0]) ? ninput_items[0] :
noutput_items;

/* use posix_memalign instead of fftwf_malloc
gr_complex *rot;
int mem = posix_memalign((void**)rot, volk_get_alignment(),
num*sizeof(gr_complex));
if(mem != 0) {
fprintf(stderr,ERROR: allocation of aligned memory failed\n);
exit(EXIT_FAILURE);
return 0;
}
*/

gr_complex *rot = (gr_complex*)fftwf_malloc(sizeof(gr_complex)*num);
if(rot == 0) {
fprintf(stderr,ERROR: allocation of aligned memory failed\n);
exit(EXIT_FAILURE);
return 0;
}

// asign values to rot
for(size_t i=0;inum;i++) {
rot[i] = gr_complex(0.1f,0.0f);
}

// invoking the unaligned version does not segfault
//volk_32fc_x2_multiply_32fc_u(out, in, rot, num);

if(is_unaligned()) {
volk_32fc_x2_multiply_32fc_u(out, in, rot, num);
} else {
// segfault
volk_32fc_x2_multiply_32fc_a(out, in, rot, num);
}

// use free for posix_memalign
//free(rot);
fftw_free(rot);

consume_each(num);
return num;
}


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio