I & Q channels in source module

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:

  : gr::sync_block("usbradio",
          gr::io_signature::make(1, 1, sizeof(short)),
          gr::io_signature::make(1, 1, sizeof(short)))
           state = 0;
           cnt = 0;

 * Our virtual destructor.

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+>

    // 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

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


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]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]


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

           state = 0;
           cnt = 0;

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
with them. These lines will make assumptions about the flow of data that
will likely hurt how you process things in the work function.


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