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: [EMAIL PROTECTED]
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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
