I & Q channels in source module

GNU Radio
1

I am writing a source module/block and I generate 16 bit signed I and Q
values. There is first a 16 bit I value then a 16 bit Q value repeated
1024 times.

In my source module I have:

usbradio_impl::usbradio_impl()
  : gr::sync_block("usbradio",
          gr::io_signature::make(1, 1, sizeof(short)),
          gr::io_signature::make(1, 1, sizeof(short)))
{
           state = 0;
           cnt = 0;
           set_max_noutput_items(1);
           set_max_output_buffer(2);
}

/*
 * Our virtual destructor.
 */
usbradio_impl::~usbradio_impl()
{
}

int
usbradio_impl::work(int noutput_items,
                      gr_vector_const_void_star &input_items,
                      gr_vector_void_star &output_items)
{
    short  *out = (short *) output_items[0];

    // Do <+signal processing+>
    stuff_output(out);

    // Tell runtime system how many output items we produced.
    return 1024;
}

The stuff_output(out) function will stuff an I value then a Q value 512
times.

Is that the correct way to present I & Q values?

Thx,
Y-

2

In general, radios that use complex-baseband format interleave I/Q in
the way you’re apparently using here. That’s very conventional.

It’s very usual for the interface to “present” complex-float to Gnu
Radio as the default format, since the vast majority of DSP blocks
operate on complex-float or float. Not a show-stopper, since blocks
exist to convert from signed-short formats into complex-float, but it’s
a nice convenience for users.

On 2015-04-23 15:09, Yile Ku wrote:

cnt = 0;

// Tell runtime system how many output items we produced.
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page [1]

Links:

3

On Thu, Apr 23, 2015 at 3:09 PM, Yile Ku [email protected] wrote:

{
           state = 0;
           cnt = 0;
           set_max_noutput_items(1);
           set_max_output_buffer(2);
}

Why are you using set_max_noutput_items and set_max_output_buffer like
this? Those numbers don’t make any sense. These are fairly advanced
features that you should only use if you know /exactly/ what you are
doing
with them. These lines will make assumptions about the flow of data that
will likely hurt how you process things in the work function.

Tom