Re: [Discuss-gnuradio] MSB

[Eric Blossom]

On Fri, Mar 16, 2007 at 01:26:08PM +0100, Davide Anastasia wrote:
> Il giorno gio, 15/03/2007 alle 12.17 -0700, Eric Blossom ha scritto:
> > I think you'll find it easier to do the unpacking in a separate block
> > downstream from the usrp1_source_s.  Modifying usrp1_source* to handle
> > samples smaller than 1 byte is going to take quite a bit of work.
> > Part of the problem is that the code is written in terms of functions
> > such as sizeof_basic_sample() which returns a size in bytes.  In your
> > case, your basic sample is smaller than a byte.  The current code
> > doesn't know how to deal with that.
> 
> I'm think about this question since I turn on my PC today. :)
> Ok, I receive from USRP a stream of samples. They are raw, not packed.
> So, if I use a 1 bit quantization, I have 8 samples in a byte; with 2
> bit, 4 samples... and so on! But any module in GNU radio uses only char,
> short, gr_complex (std::complex, is the same?). If I change
> usrp1_source* to return always * samples, I reach my purpose. And then,
> after usrp1_source*, I can use every module in the library I need.
> 
> What's my fault(s) in this reasoning?
> -- 
> Davide Anastasia
> 
> web: http://www.davideanastasia.com/
> email: address@hidden

No particular fault.  However, the outputs from the USRP are almost
always some kind of complex values.  They may be encoded as 16-bit I &
Q, or 8-bit I & Q or 4-bit or 2-bit or 1-bit.  The question is how do
we want to deal with them downstream from the USRP?  The existing
usrp.source_s could be considered broken (although there are users of
it.)  The data is really interleaved 16-bit I & Q, though it's
presented as if each sample was only 16-bits wide.  In fact a "sample"
is really composed of 2 16-bit values.


One way to approach this is to modify usrp.source_c so that it
internally handles the format conversion, and always produces
gr_complex as its output type.

When dealing with 1 bit samples, there is the question of whether you
want to treat them as -1, +1 or  0, +1.  I suspect that -1, +1 makes
more sense, but on the other hand, treating them as -32767, 32767
would be consistent with how the 8-bit samples are handled.  That is,
they are multiplied by 256 so that they fill the same range as the
"normal" 16-bit I & Q.

Another thought is to define a new complex interface that always
returns values normalized to [-1.0, +1.0].

Eric