|Subject:||Re: [Discuss-gnuradio] Pack k bits?|
|Date:||Fri, 30 Mar 2012 20:33:32 +0000|
Any comment on this? I think the current implementation of gr_packed_to_unpacked_bb(int k, gr_endianness_t endianness) puts bits in an incorrect order when k > 1 and endianness = gr.GR_LSB_FIRST.
I think it would work if I modified gnuradio/gnuradio-core/src/lib/gengen/gr_packed_to_unpacked_XX.cc.t (line 119) to the following:
x = (x>>1) | (get_bit_le(in, index_tmp) << (d_bits_per_chunk - 1) );
x |= get_bit_le(in, index_tmp) << j;
I haven’t tested, but I think these are functionally equivalent. Does this change sound reasonable?
I want to take an input stream of bytes in which only one LSB is relevant (e.g., the output of the GR GLFSR block) and pack these bits into bytes with k relevant bits. For example, I’d like to take a stream of raw bits generated by the GLFSR and feed them to an M-PSK modulator, which requires chunks with k=log2(M) bits. Unfortunately I haven’t found this to be straightforward. There is no “pack_k_bits” module that I could find, so I tried using unpacked_to_packed_bb and packed_to_unpacked_bb. They are not working like I would expect. For instance, here’s an example in Python:
data = "" 0,0,1,0, 1,1,1,0, 0,1,1,0] # 45 67
self.source = gr.vector_source_b(data, False, 1)
self.pack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST)
self.unpack = gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST) # stuff 2 bits into LSB of each output byte
self.head = gr.head(gr.sizeof_char, 8) # should have 16/2 = 8 output bytes
self.sink = gr.file_sink(gr.sizeof_char, “out.bin”)
self.connect(self.source, self.pack, self.unpack, self.head, self.sink)
This gives the following:
$ hexdump -C out.bin
0000000 02 02 00 02 03 02 01 02 |……..|
But I would expect the following:
0000000 01 01 00 01 03 01 02 01 |……..|
Notice that the two least significant bits are in reverse order. Any clue what’s going on here?
|[Prev in Thread]||Current Thread||[Next in Thread]|