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 can use the "format()" function to obtain the width of the sample.
Actually I'm using this way:
case 1:
for (int i = 0; i < nitems; i++){
switch ( format() ) {
case 1:
out[i] = usrp_to_host_short(s16[i]);
// temp = 0 | s8[i] << 8;
// i++;
// out[i] = temp | s8[i]; // Si può fare?
break;
case 2:
out[i] = s8[i] << 14;
break;
case 4:
out[i] = s8[i] << 12;
break;
case 8:
default:
out[i] = s8[i] << 8;
}
}
break;
I change sizeof_basic_sample() in order to return 1 with samples smaller
than a byte. I written a little C++ program to obtain from a 1 bit
stream a table (#, value{0 or 1}). I think it can been reused to create
a module, which take a stream and return a 16 bit sample per bit.
>
> After unpacking, what representation do you want for your samples?
I guess a simple continuos stream of bit is enough.
>
> If bytes containing 1-bit per byte are OK, then perhaps the easiest
> approach is to create a gr_packed_to_unpacked_sb.*
>
> You should be able to do this by changing:
>
> # other blocks
> others = (
> ('gr_chunks_to_symbols_XX', ('bf', 'bc', 'sf', 'sc', 'if',
> 'ic')),
> ('gr_unpacked_to_packed_XX', ('bb','ss','ii')),
> ('gr_packed_to_unpacked_XX', ('bb','ss','ii'))
> )
>
>
> to
>
> # other blocks
> others = (
> ('gr_chunks_to_symbols_XX', ('bf', 'bc', 'sf', 'sc', 'if',
> 'ic')),
> ('gr_unpacked_to_packed_XX', ('bb','ss','ii')),
> ('gr_packed_to_unpacked_XX', ('bb','ss','ii', 'sb'))
> )
>
> in gnuradio-core/src/lib/gengen/generate_common.py
"b" stays for byte or bit?
>
> On the other hand, I assume that ultimately these end up as some kind
> of complex data type, so perhaps some other kind of mapping to
> gr_complex would be useful.
--
Davide Anastasia
web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
