Input items vs Output items

I am slightly confused with the way you implement a general work
function - here is my AX25 decoder which takes in bits and outputs
decoded packets in text format as a stream of 8 bit integers. This was
based on the general work example in the GR tutorial.

int ax25_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
int i;
const char *bit = (const char *) input_items[0];
out = (char *) output_items[0];

d_numchars=0;
for (i=0;i <noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}

// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}

I keep a tally of how many characters I output in the class member
variable d_numchars. I do this by initially printing to the “out”
buffer (see above code) with the vsprintf() function and then using
the strlen() function to find out how long the out string is.

It works for a while, perhaps 200-300 packets and then crashes with a
segfault and error 7. I know the crash is related to the number of
output items because if I reduce the number of characters I output it
will run for longer. If I don’t output anything its fine, but not very
useful.

It gets complicated because the block outputs nothing at all until it
decodes a packet, then it outputs that entire packet, which might be
up to 1000 characters or so.

I think I have made a fundamental error somewhere. Finding it is
proving problematic. I am also confused by ninput_items and
noutput_items variables as to me they appear reversed but that is how
they are in the tutorial.

Mike

I should have added, the packet decoding is based on Volkers rather
nifty gr-ax25, which I think is based on earlier implementations so I
don’t think that is where the bug is. I have heavily modified that code
as I am using BPSK demodulator but the hdlc parts are the same.

Mike

Hi Mike,

you might actually be doing something redundant here:
GNU Radio actually keeps tabs on how many items you produced; just call
nitems_written(0) to get that number.

I don’t really understand where your string comes from or where it ends
up, but do make sure your string isn’t going to be longer than your
noutput_items.

Generally, this is something that can most probably best be analyzed
using appropriate debugging methods – I’d like to point you to [1].
As soon as you find out where your segfault happens, it will be easier
to understand under which conditions it happens. Also, GDB allows you to
print the value of local variables, so that might actually shine quite
a light on what goes wrong :slight_smile:

On a more general note: what your block seems to do looks very much like
what tagged stream blocks (probably after gr-ax25) were designed to do.
Have a look at [2]; maybe I’m misjudging the situation, maybe you’re
already using the TSB facilities.

Greetings,
Marcus

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
[2] http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html

Also, to point out existing work, there is an HDLC framer and deframer
in
Gnuradio now. The deframer takes in a byte stream, 1 bit per byte, and
outputs PDUs with your HDLC frames.

–n

On Sat, Apr 18, 2015 at 6:46 AM, Marcus Müller
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs