---------- Forwarded message ----------
From: Mostafa Alizadeh <m.alizade...@gmail.com>
Date: Mon, Jul 28, 2014 at 7:21 PM
Subject: Re: [Discuss-gnuradio] Problem with large number of inputs.
To: Activecat <active...@gmail.com>
Dear Activecat,
I run the whole GNURadio C++ codes in Qtcreator without any problem by
adding these lines to its .pro file:
LIBS += /usr/lib/libboost_signals.so\
/usr/lib/libboost_signals.so.1.48.0\
/usr/lib/libboost_system-mt.so\
/usr/lib/libboost_system.so\
/usr/lib/libboost_system.so.1.48.0\
/usr/lib/libboost_thread-mt.so\
/usr/lib/libboost_thread.so\
/usr/lib/libboost_thread.so.1.48.0\
/usr/lib/libboost_timer-mt.so\
/usr/lib/libboost_timer.so\
-L/usr/local/lib -lgnuradio-audio -lgnuradio-runtime -lgnuradio-pmt
-lgnuradio-blocks -lgnuradio-filter
LIBS+= -L/usr/local/lib -lgnuradio-analog -lgnuradio-runtime
-lgnuradio-pmt -lgnuradio-audio -lgnuradio-blocks -lgnuradio-filter
LIBS+=-lboost_system -lboost_thread-mt -lboost_thread
-lboost_filesystem-mt -lboost_filesystem -lgnuradio-qtgui
-lgnuradio-fft
LIBS += -lfftw3f -lfftw3 \
I didn't reveal the big picture because I thought I doesn't help to
figure out the problem :)
I finally found the problem! That was so hard to me to do so! I
suddenly recognized that the proceeding block which is connected to
input ports of this block , have a problem and that is, I set the item
sizes of the previous blocks output as gr_complex but in its work
function I set the pointer to the ouput_items as "byte" instead of
gr_complex!!!
Anyway, I have to thank all of you following my questions sincerely.
Best,
Mostafa
On Mon, Jul 28, 2014 at 8:46 AM, Activecat <active...@gmail.com> wrote:
> Mostafa,
>
> I do not think you have truly run the complete codes using Qtcreator,
> because that doesn't have a gnuradio runtime (the scheduler).
> At the other hand, your problem sounds more like a c++ coding error rather
> than gnuradio-specific.
> The helpful approach is
>
> 1). Put up the OOT into github.
> This should be the simplest but complete OOT.
>
> 2). Provide a big picture of what you try to accomplish.
> From experience many amateur programmers write codes wrong from the
> ground up, and yet expect others to troubleshoot.
> When this happens, the only way to help is to start with the big
> picture of what you wish to accomplish.
>
> From previous experience you refused to reveal the big picture but
> emphasize others to look at your existing buggy codes.
> Please be reminded that this is an open forum and nobody get paid for
> helping you.
>
>
> On Mon, Jul 28, 2014 at 7:39 AM, Mostafa Alizadeh <m.alizade...@gmail.com>
> wrote:
>
>> I forgot to say, I'm using Qtcreator to debug my GNURadio codes I do not
>> need any others!
>>
>> The prgram is terminated at line in which I read from the input for the
>> first time i.e. :
>>
>> y_p[i][k] = 0;
>> for (int j=0; j<N_FS_phich(d_normal_cp); j++)
>> {
>> y_p[i][k] = y_p[i][k] + in[i*8+j][k];
>> }
>>
>> Best,
>>
>>
>> On Mon, Jul 28, 2014 at 4:05 AM, Mostafa Alizadeh <m.alizade...@gmail.com
>> > wrote:
>>
>>> Yes you're right about casting between "in" and "input_items", however,
>>> I think this problem is somehow related to the large number input ports! I
>>> don't why!
>>>
>>> Here is the whole block:
>>>
>>> #ifdef HAVE_CONFIG_H
>>> #include "config.h"
>>> #endif
>>>
>>> #include <gnuradio/io_signature.h>
>>> #include "phich_grouping_impl.h"
>>>
>>> int N_FS_phich(bool normal_cp){
>>> if(normal_cp)
>>> return 8;
>>> else
>>> return 4;
>>> }
>>>
>>> namespace gr {
>>> namespace my {
>>>
>>> phich_grouping::sptr
>>> phich_grouping::make(bool normal_cp, int N_phich_group)
>>> {
>>> return gnuradio::get_initial_sptr
>>> (new phich_grouping_impl(normal_cp, N_phich_group));
>>> }
>>>
>>> /*
>>> * The private constructor
>>> */
>>> phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
>>> N_phich_group)
>>> : gr::block("phich_grouping",
>>> gr::io_signature::make(N_phich_group *
>>> N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
>>> sizeof(gr_complex)),
>>> gr::io_signature::make(1, 1, sizeof(gr_complex))),
>>> d_normal_cp(normal_cp),
>>> d_N_phich_group(N_phich_group)
>>> {
>>> set_tag_propagation_policy(TPP_DONT);
>>>
>>> }
>>>
>>> /*
>>> * Our virtual destructor.
>>> */
>>> phich_grouping_impl::~phich_grouping_impl()
>>> {
>>> }
>>>
>>> void
>>> phich_grouping_impl::forecast (int noutput_items, gr_vector_int
>>> &ninput_items_required)
>>> {
>>> for (int i=0; i<d_N_phich_group * N_FS_phich(d_normal_cp); i++)
>>> {
>>> ninput_items_required[i] = 12;
>>> }
>>> }
>>>
>>> int
>>> phich_grouping_impl::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[d_N_phich_group * N_FS_phich(d_normal_cp)];
>>> gr_complex *out = (gr_complex *) output_items[0];
>>> // in = (const gr_complex *) input_items;
>>>
>>> cout << "n input " << input_items.size() << endl;
>>> int phich_in_len[d_N_phich_group];
>>>
>>> int x = 0;
>>> for (int i=0; i<d_N_phich_group * N_FS_phich(d_normal_cp); i++)
>>> {
>>> in[i] = (const gr_complex *) input_items[i];
>>>
>>> // reading tags
>>> vector<tag_t> tag_len;
>>> get_tags_in_window(tag_len,
>>> 0,
>>> 0,
>>> ninput_items[0],
>>> pmt::string_to_symbol("length"));
>>> if(tag_len.size()>0)
>>> {
>>> phich_in_len[i] = pmt::to_long(tag_len[0].value);
>>> x++;
>>> }
>>>
>>> }
>>>
>>> gr_complex y_p[d_N_phich_group][12];
>>> gr_complex y__p_tilt[d_N_phich_group/2][12];
>>>
>>> // cout << "\tin[0][0] "<<in[0][0] << endl;
>>>
>>> if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
>>> d_N_phich_group) is for checking all the input tags are read
>>> {
>>> // grouping ...
>>> for (int i=0; i<d_N_phich_group ;i++)
>>> {
>>> for (int k=0; k<phich_in_len[i]; k++)
>>> {
>>> y_p[i][k] = 0;
>>> for (int j=0; j<N_FS_phich(d_normal_cp); j++)
>>> {
>>> y_p[i][k] = y_p[i][k] + in[i*8+j][k];
>>> }
>>> }
>>>
>>> }
>>>
>>> ........
>>> .......
>>> ...........
>>>
>>>
>>> // adding tag
>>> add_item_tag(0,
>>> nitems_written(0),
>>> pmt::string_to_symbol("length"),
>>> pmt::from_long(12));
>>>
>>> cout << "PHICH grouping" << endl;
>>>
>>> consume_each(12);
>>>
>>> }
>>> else
>>> { // if tags didn't read
>>> produce(0, 0);
>>> consume_each(0);
>>> }
>>>
>>>
>>> return WORK_CALLED_PRODUCE;
>>> }
>>>
>>> } /* namespace my */
>>> } /* namespace gr */
>>>
>>>
>>> Input to this block is a random source and its output is a file sink. I
>>> would be glad to see the comments on the code to improve it also finding
>>> the problem.
>>>
>>> Best,
>>> Mostafa Alizadeh
>>>
>>>
>>>
>>> On Sun, Jul 27, 2014 at 10:10 PM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
>>>> As I said, you should use the gdb debugging approach to find the
>>>> mistake.
>>>> gr_complex **in = (gr_complex) input_items; shouldn't compile, because
>>>> the types are incompatible.
>>>>
>>>> I can't help you any further with the information you're offering.
>>>> Please share at least your complete general_work method, and the methods
>>>> that you use to calculate the input numbers. I stand by my opininion
>>>> that beauty lies in simplicity. If you want to make sure you don't do
>>>> more "for" iterations than you have inputs, iterate over the number of
>>>> inputs (input_items.size()) and not something you calculate yourself.
>>>> That's the simple approach of eliminating error sources.
>>>>
>>>> Also, you're using a gr::block. If you play around with the forecast
>>>> method, you might trigger situations where you are asked to produce a
>>>> number of output items on different output streams, and have zero input
>>>> items on some input streams; I don't see you check for that in the code
>>>> excerpt you were sharing.
>>>> Again, it isn't very useful to share only a portion of your block,
>>>> especially when you are very sure yourself that this portion is correct,
>>>> if you want help identifying what goes wrong.
>>>>
>>>> With best regards,
>>>> Marcus Müller
>>>>
>>>> On 27.07.2014 19:21, Mostafa Alizadeh wrote:
>>>> > Thank you for your notes Marcus,
>>>> >
>>>> > As you said this is unnecessary process to point to the input_items
>>>> in a
>>>> > for loop!!
>>>> > However, this is not the problem because I checked that I have the
>>>> same
>>>> > number of iteration in the for loop as the number of input ports.
>>>> >
>>>> > The problem is somewhere else. *Again I must mention that if I use,
>>>> only 8
>>>> > input ports, the code runs perfectly,* however, with 24 inputs, it
>>>> does
>>>> > something wrong! (perhaps pointing to somewhere in the memory which
>>>> is not
>>>> > allocated to the input as it seemed to allocated to the input!). In
>>>> another
>>>> > words, when I want to access the first input of the first input port,
>>>> I can
>>>> > write:
>>>> >
>>>> > gr_complex **in = (gr_complex) input_items;
>>>> >
>>>> > // for example
>>>> > cout << in[0][0] << endl;
>>>> >
>>>> >
>>>> > The program terminated with unexpected error!
>>>> >
>>>> > Please help me, where is the problem?? :(
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Sun, Jul 27, 2014 at 4:21 AM, Marcus Müller <
>>>> marcus.muel...@ettus.com>
>>>> > wrote:
>>>> >
>>>> >> Having your complete general_work function wouldn't have hurt my
>>>> >> understanding much...
>>>> >>
>>>> >> I really can't make out what you're trying to do without doubt.
>>>> >>
>>>> >> Anyway, from the code below I think "in" *must at least* have the
>>>> same
>>>> >> number of entries that your for loop has iterations; did you just
>>>> try using
>>>> >>
>>>> >> d_group * N_FS(d_normal) instead of d_N_phich_group *
>>>> >> N_FS_phich(d_normal_cp) when allocating your array?
>>>> >> It seems to me that having two ways to determine how many inputs
>>>> there is
>>>> >> a likely cause for mistake. Use the size() of the input_items to
>>>> determine
>>>> >> how many inputs you really have, and assert(input_items.size() ==
>>>> >> number_of_inputs_like_I_calculate_it); to make sure things line up.
>>>> >>
>>>> >> Also, the whole process seems unnecessary, since you do nothing more
>>>> than
>>>> >> copying the pointers from input_items to in; the typecast is nothing
>>>> but
>>>> >> syntactic magic and can be done by having "in = ((const
>>>> gr_complex*)*)
>>>> >> input_items;"; also, I encourage you to use the C++-style explicit
>>>> cast
>>>> >> operators (in this case, reinterpret_cast<>) for their clarity, but
>>>> that's
>>>> >> more a question of personal liking :)
>>>> >>
>>>> >> Greetings,
>>>> >> Marcus
>>>> >>
>>>> >> On 26.07.2014 21:55, Mostafa Alizadeh wrote:
>>>> >>> Hi Marcus,
>>>> >>>
>>>> >>> You're right. I didn't clarify the problem.
>>>> >>>
>>>> >>> Actually in C++, I wrote:
>>>> >>>
>>>> >>> block_impl::block_impl(bool normal, int group)
>>>> >>> : gr::block("phich_grouping",
>>>> >>> gr::io_signature::make(1, group * N_FS(normal),
>>>> sizeof
>>>> >>> (gr_complex)),
>>>> >>> gr::io_signature::make(1, 1, sizeof(gr_complex))),
>>>> >>>
>>>> >>> // N_FS function returns 8 or 4 depends on its input.
>>>> >>> // in the work function :
>>>> >>> // d_normal and d_group are defined in the .h file
>>>> >>>
>>>> >>>
>>>> >>> const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
>>>> >>> for (int i=0; i<d_group * N_FS(d_normal); i++)
>>>> >>> {
>>>> >>> in[i] = (const gr_complex *) input_items[i];
>>>> >>> }
>>>> >>>
>>>> >>>
>>>> >>> when I set the "group" value to 3, the number of input ports would
>>>> be 24.
>>>> >>> In this case, I want to access to one element of "in" like this:
>>>> >>>
>>>> >>> cout << " in " << in[0][0] << endl;
>>>> >>>
>>>> >>> I got the aforementioned error!
>>>> >>>
>>>> >>> But when I set "group = 1" which means 8 input ports, all things are
>>>> >> fine.
>>>> >>>
>>>> >>> any idea please,
>>>> >>>
>>>> >>> Best
>>>> >>>
>>>> >>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
